You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Anil Gangolli <an...@busybuddha.org> on 2010/02/08 16:17:47 UTC
location of db creation and migration scripts in Roller 5
Dave et al.
After building off the recently mavenized trunk, I found that the real
db scripts end up inside the roller-weblogger-business jar under the
classpath /sql/<dbtype>/. There are still a number of older ones ending
up in the exploded war
target/roller/WEB-INF/classes/dbscripts/<dbtype>. These probably ought
to go away or be unified with the new ones.
The ClasspathDatabaseScriptProvider is prepending the old path
("/dbscripts/" instead of "/sql/") and not finding the createdb.sql for
automatic creation/upgrade.
It's easy enough to fix the path formation (which I intend to commit to
trunk for now, just so it will work), but I think we ought to consider
whether having the scripts in the jar is the right thing. It makes any
kind of manual execution or tweaking harder.
On a separate, but related note, once I fixed the problem locating the
createdb.sql resource, the execution of it by the auto installer is
failing after about six tables complaining of an error reading or
parsing the script. If I manually extract the script from the jar and
run it via mysql, it seems to work fine. I am still debugging what is
causing that. It might be some kind of line termination issue or
platform-specific issue. I am currently working on a Mac.
--a.
Re: location of db creation and migration scripts in Roller 5
Posted by Dave <sn...@gmail.com>.
That was entirely my mistake and I'll fix things so that they work as
they did in 4.0, with the scripts in WEB-INF/classes/dbscripts.
- Dave
On Mon, Feb 8, 2010 at 10:39 AM, Anil Gangolli <an...@busybuddha.org> wrote:
>
> I found out that the second issue is due to the fact that the
> ClasspathDatabaseScriptProvider can find the createdb.sql script in the
> roller-planet-business jar instead of the roller-weblogger-business jar.
> You can get lucky and find the right one or unlucky and pick up the wrong
> one (from the planet jar) at autoinstall time.
>
> Also (separate issue) the SQLScriptRunner class has a problem parsing the
> one from the planet jar because of the way it ends in comment lines. It
> needs to end in a statement.
>
> I think this says we need the scripts to all end up somewhere under
> WEB-INF/classes which is prioritized by the class loader, or we need to
> start naming things distinctly and distinguishing at auto-install time. The
> latter might be better, but would require some additional code and build
> change.
>
> Comments?
>
>
> On 2/8/10 7:17 AM, Anil Gangolli wrote:
>>
>> Dave et al.
>>
>> After building off the recently mavenized trunk, I found that the real db
>> scripts end up inside the roller-weblogger-business jar under the classpath
>> /sql/<dbtype>/. There are still a number of older ones ending up in the
>> exploded war target/roller/WEB-INF/classes/dbscripts/<dbtype>. These
>> probably ought to go away or be unified with the new ones.
>>
>> The ClasspathDatabaseScriptProvider is prepending the old path
>> ("/dbscripts/" instead of "/sql/") and not finding the createdb.sql for
>> automatic creation/upgrade.
>>
>> It's easy enough to fix the path formation (which I intend to commit to
>> trunk for now, just so it will work), but I think we ought to consider
>> whether having the scripts in the jar is the right thing. It makes any kind
>> of manual execution or tweaking harder.
>>
>> On a separate, but related note, once I fixed the problem locating the
>> createdb.sql resource, the execution of it by the auto installer is failing
>> after about six tables complaining of an error reading or parsing the
>> script. If I manually extract the script from the jar and run it via mysql,
>> it seems to work fine. I am still debugging what is causing that. It might
>> be some kind of line termination issue or platform-specific issue. I am
>> currently working on a Mac.
>>
>> --a.
>>
>
>
Re: location of db creation and migration scripts in Roller 5
Posted by Anil Gangolli <an...@busybuddha.org>.
I found out that the second issue is due to the fact that the
ClasspathDatabaseScriptProvider can find the createdb.sql script in the
roller-planet-business jar instead of the roller-weblogger-business
jar. You can get lucky and find the right one or unlucky and pick up
the wrong one (from the planet jar) at autoinstall time.
Also (separate issue) the SQLScriptRunner class has a problem parsing
the one from the planet jar because of the way it ends in comment
lines. It needs to end in a statement.
I think this says we need the scripts to all end up somewhere under
WEB-INF/classes which is prioritized by the class loader, or we need to
start naming things distinctly and distinguishing at auto-install time.
The latter might be better, but would require some additional code and
build change.
Comments?
On 2/8/10 7:17 AM, Anil Gangolli wrote:
> Dave et al.
>
> After building off the recently mavenized trunk, I found that the real
> db scripts end up inside the roller-weblogger-business jar under the
> classpath /sql/<dbtype>/. There are still a number of older ones
> ending up in the exploded war
> target/roller/WEB-INF/classes/dbscripts/<dbtype>. These probably
> ought to go away or be unified with the new ones.
>
> The ClasspathDatabaseScriptProvider is prepending the old path
> ("/dbscripts/" instead of "/sql/") and not finding the createdb.sql
> for automatic creation/upgrade.
>
> It's easy enough to fix the path formation (which I intend to commit
> to trunk for now, just so it will work), but I think we ought to
> consider whether having the scripts in the jar is the right thing. It
> makes any kind of manual execution or tweaking harder.
>
> On a separate, but related note, once I fixed the problem locating the
> createdb.sql resource, the execution of it by the auto installer is
> failing after about six tables complaining of an error reading or
> parsing the script. If I manually extract the script from the jar and
> run it via mysql, it seems to work fine. I am still debugging what is
> causing that. It might be some kind of line termination issue or
> platform-specific issue. I am currently working on a Mac.
>
> --a.
>