Alternative to Sam's "migrate"

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Alternative to Sam's "migrate"

Nathan Voxland-2
I created an alternative to the dbmigrate-based "migrate" plugin that is
based on liquibase instead.  

It is currently available at
http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
underlying engine is LiquiBase 1.3 which is production-ready.

I had started it before Sam released his plug-in and wanted to at least
finish it up and see what everyone thought.

The currently implanted functionality includes:

liquibase-migrate
liquibase-migrateSQL
liquibase-tag <tag>
liquibase-rollback <tag>
liquibase-rollbackCount <num>
liquibase-rollbackSQL <tag>
liquibase-rollbackCountSQL <num>

Set up your database using the standard
grails-app/conf/DataSource.groovy file

Add your database changes to the grails-app/migrations/changelog.xml
file

A starting changelog.xml is:

<?xml version="1.0" encoding="UTF-8"?>

<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">

</databaseChangeLog>

Full documentation on LiquiBase in general is available at
http://www.liquibase.org.  I have yet to create any grails docs beyond
this email :)



Some questions I have:
1. Does it make sense to have liquibase- appended to all the command
names?  I was concerned that I would run into other installed plug-ins
without them.  Is there a better way to specify them?

2. The change logs are all currently XML based, which I know isn't
particularly grails-y.  How much of a turn-off is that for everyone?  I
plan to create a DSL version of the change log at some point, but so far
it hasn't been a high priority.

3. Is there a way to use the release-plugin functionality if I don't
host the code in your SVN repository?

4. Does it make sense to have more than one database migrate plug-in
available for Grails?  My plug-in is mainly a grails wrapper around an
existing database migrator tool whereas Sam's seems to be more of a
grails app from the start.  I tend to think the more options the better,
but it may lead to end-user confusion.  

Nathan

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Guillaume Laforge-2
Waoh, this sounds like an advanced migration system!
I've never found time to play with Liquibase so far, but this stuff
looks pretty powerful.
Well done.

On 10/3/07, Nathan Voxland <[hidden email]> wrote:

> I created an alternative to the dbmigrate-based "migrate" plugin that is
> based on liquibase instead.
>
> It is currently available at
> http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> underlying engine is LiquiBase 1.3 which is production-ready.
>
> I had started it before Sam released his plug-in and wanted to at least
> finish it up and see what everyone thought.
>
> The currently implanted functionality includes:
>
> liquibase-migrate
> liquibase-migrateSQL
> liquibase-tag <tag>
> liquibase-rollback <tag>
> liquibase-rollbackCount <num>
> liquibase-rollbackSQL <tag>
> liquibase-rollbackCountSQL <num>
>
> Set up your database using the standard
> grails-app/conf/DataSource.groovy file
>
> Add your database changes to the grails-app/migrations/changelog.xml
> file
>
> A starting changelog.xml is:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <databaseChangeLog
>         xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
>         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
>
> </databaseChangeLog>
>
> Full documentation on LiquiBase in general is available at
> http://www.liquibase.org.  I have yet to create any grails docs beyond
> this email :)
>
>
>
> Some questions I have:
> 1. Does it make sense to have liquibase- appended to all the command
> names?  I was concerned that I would run into other installed plug-ins
> without them.  Is there a better way to specify them?
>
> 2. The change logs are all currently XML based, which I know isn't
> particularly grails-y.  How much of a turn-off is that for everyone?  I
> plan to create a DSL version of the change log at some point, but so far
> it hasn't been a high priority.
>
> 3. Is there a way to use the release-plugin functionality if I don't
> host the code in your SVN repository?
>
> 4. Does it make sense to have more than one database migrate plug-in
> available for Grails?  My plug-in is mainly a grails wrapper around an
> existing database migrator tool whereas Sam's seems to be more of a
> grails app from the start.  I tend to think the more options the better,
> but it may lead to end-user confusion.
>
> Nathan
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Jesse O'Neill-Oine
In reply to this post by Nathan Voxland-2
I've looked at liquibase before and the big turnoff was the XML  
changelog style, so a DSL for that part would be huge in my mind.

Nice work!

Jesse

Sent from my iPhone

On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"  
<[hidden email]> wrote:

> I created an alternative to the dbmigrate-based "migrate" plugin  
> that is
> based on liquibase instead.
>
> It is currently available at
> http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> underlying engine is LiquiBase 1.3 which is production-ready.
>
> I had started it before Sam released his plug-in and wanted to at  
> least
> finish it up and see what everyone thought.
>
> The currently implanted functionality includes:
>
> liquibase-migrate
> liquibase-migrateSQL
> liquibase-tag <tag>
> liquibase-rollback <tag>
> liquibase-rollbackCount <num>
> liquibase-rollbackSQL <tag>
> liquibase-rollbackCountSQL <num>
>
> Set up your database using the standard
> grails-app/conf/DataSource.groovy file
>
> Add your database changes to the grails-app/migrations/changelog.xml
> file
>
> A starting changelog.xml is:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <databaseChangeLog
>        xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
>        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
>
> </databaseChangeLog>
>
> Full documentation on LiquiBase in general is available at
> http://www.liquibase.org.  I have yet to create any grails docs beyond
> this email :)
>
>
>
> Some questions I have:
> 1. Does it make sense to have liquibase- appended to all the command
> names?  I was concerned that I would run into other installed plug-ins
> without them.  Is there a better way to specify them?
>
> 2. The change logs are all currently XML based, which I know isn't
> particularly grails-y.  How much of a turn-off is that for  
> everyone?  I
> plan to create a DSL version of the change log at some point, but so  
> far
> it hasn't been a high priority.
>
> 3. Is there a way to use the release-plugin functionality if I don't
> host the code in your SVN repository?
>
> 4. Does it make sense to have more than one database migrate plug-in
> available for Grails?  My plug-in is mainly a grails wrapper around an
> existing database migrator tool whereas Sam's seems to be more of a
> grails app from the start.  I tend to think the more options the  
> better,
> but it may lead to end-user confusion.
>
> Nathan
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Guillaume Laforge-2
Yeah, a DSL on top of their ugly XML would be easy to do I guess, even
if it's just a builder syntax on top of the XML.


On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:

> I've looked at liquibase before and the big turnoff was the XML
> changelog style, so a DSL for that part would be huge in my mind.
>
> Nice work!
>
> Jesse
>
> Sent from my iPhone
>
> On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> <[hidden email]> wrote:
>
> > I created an alternative to the dbmigrate-based "migrate" plugin
> > that is
> > based on liquibase instead.
> >
> > It is currently available at
> > http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> > underlying engine is LiquiBase 1.3 which is production-ready.
> >
> > I had started it before Sam released his plug-in and wanted to at
> > least
> > finish it up and see what everyone thought.
> >
> > The currently implanted functionality includes:
> >
> > liquibase-migrate
> > liquibase-migrateSQL
> > liquibase-tag <tag>
> > liquibase-rollback <tag>
> > liquibase-rollbackCount <num>
> > liquibase-rollbackSQL <tag>
> > liquibase-rollbackCountSQL <num>
> >
> > Set up your database using the standard
> > grails-app/conf/DataSource.groovy file
> >
> > Add your database changes to the grails-app/migrations/changelog.xml
> > file
> >
> > A starting changelog.xml is:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <databaseChangeLog
> >        xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> >        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >
> > xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> >
> > </databaseChangeLog>
> >
> > Full documentation on LiquiBase in general is available at
> > http://www.liquibase.org.  I have yet to create any grails docs beyond
> > this email :)
> >
> >
> >
> > Some questions I have:
> > 1. Does it make sense to have liquibase- appended to all the command
> > names?  I was concerned that I would run into other installed plug-ins
> > without them.  Is there a better way to specify them?
> >
> > 2. The change logs are all currently XML based, which I know isn't
> > particularly grails-y.  How much of a turn-off is that for
> > everyone?  I
> > plan to create a DSL version of the change log at some point, but so
> > far
> > it hasn't been a high priority.
> >
> > 3. Is there a way to use the release-plugin functionality if I don't
> > host the code in your SVN repository?
> >
> > 4. Does it make sense to have more than one database migrate plug-in
> > available for Grails?  My plug-in is mainly a grails wrapper around an
> > existing database migrator tool whereas Sam's seems to be more of a
> > grails app from the start.  I tend to think the more options the
> > better,
> > but it may lead to end-user confusion.
> >
> > Nathan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

graemer
In reply to this post by Nathan Voxland-2
On 10/3/07, Nathan Voxland <[hidden email]> wrote:

> I created an alternative to the dbmigrate-based "migrate" plugin that is
> based on liquibase instead.
>
> It is currently available at
> http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> underlying engine is LiquiBase 1.3 which is production-ready.
>
> I had started it before Sam released his plug-in and wanted to at least
> finish it up and see what everyone thought.
>
> The currently implanted functionality includes:
>
> liquibase-migrate
> liquibase-migrateSQL
> liquibase-tag <tag>
> liquibase-rollback <tag>
> liquibase-rollbackCount <num>
> liquibase-rollbackSQL <tag>
> liquibase-rollbackCountSQL <num>
>
> Set up your database using the standard
> grails-app/conf/DataSource.groovy file
>
> Add your database changes to the grails-app/migrations/changelog.xml
> file
>
> A starting changelog.xml is:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <databaseChangeLog
>         xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
>         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
>
> </databaseChangeLog>
>
> Full documentation on LiquiBase in general is available at
> http://www.liquibase.org.  I have yet to create any grails docs beyond
> this email :)
>
>

Hi Nathan,

Looks like great work. Would be nice if it was published to the Grails
standard repo:

http://svn.grails-plugins.codehaus.org/

I'll see if I can answer some of your questions...

>
> Some questions I have:
> 1. Does it make sense to have liquibase- appended to all the command
> names?  I was concerned that I would run into other installed plug-ins
> without them.  Is there a better way to specify them?

I dont think it is needed, even if multiple plugins have the same name
Grails will ask which one you want to run. So if you have a two
targets called  "migrate" Grails will ask which one you want to
execute.

>
> 2. The change logs are all currently XML based, which I know isn't
> particularly grails-y.  How much of a turn-off is that for everyone?  I
> plan to create a DSL version of the change log at some point, but so far
> it hasn't been a high priority.

Yes, I think XML will be a big turn off for some, certainly if you
there was a Groovy DSL version it would attract more users. We were
looking to add this functionality to Grails after 1.0 so maybe we can
help out here or with Sam's effort (I havent had a change to evaluate
either)
>
> 3. Is there a way to use the release-plugin functionality if I don't
> host the code in your SVN repository?

Not currently. You could open the
GRAILS_HOME/scripts/ReleasePlugin.groovy file and change the pluginSVN
variable to point to your repo though. However ideally it would be
great if it was hosted in the Grails standard SVN repo.

Otherwise I guess we should think about adding functionality to make
the repos Grails looks for plugins in customisable

>
> 4. Does it make sense to have more than one database migrate plug-in
> available for Grails?  My plug-in is mainly a grails wrapper around an
> existing database migrator tool whereas Sam's seems to be more of a
> grails app from the start.  I tend to think the more options the better,
> but it may lead to end-user confusion.

I dont think there is anything wrong with choice. However as I
mentioned we were looking to have a standardised plugin, but I will
need to evaluate what tech to base it on after 1.0

Cheers
>
> Nathan
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: Alternative to Sam's "migrate"

Nathan Voxland-2
Thanks for the answers.  The reason I would like to keep it in my SVN
repository is so that whenever anyone checks out the main liquibase
module they will get the grails code as well.  

If the only way to get the plug-in in to work with list-plugins and
install-plugin is to move the grails code to your svn, I think that is
more important than keeping all our code together.  I'm not sure how the
install-plugin works, but if there was a way for me to upload the built
zip to a particular location, that would maybe work best.

Nathan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Graeme Rocher
Sent: Wednesday, October 03, 2007 4:15 PM
To: [hidden email]
Subject: Re: [grails-dev] Alternative to Sam's "migrate"

On 10/3/07, Nathan Voxland <[hidden email]> wrote:
> I created an alternative to the dbmigrate-based "migrate" plugin that
is
> based on liquibase instead.
>
> It is currently available at
> http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> underlying engine is LiquiBase 1.3 which is production-ready.
>
> I had started it before Sam released his plug-in and wanted to at
least

> finish it up and see what everyone thought.
>
> The currently implanted functionality includes:
>
> liquibase-migrate
> liquibase-migrateSQL
> liquibase-tag <tag>
> liquibase-rollback <tag>
> liquibase-rollbackCount <num>
> liquibase-rollbackSQL <tag>
> liquibase-rollbackCountSQL <num>
>
> Set up your database using the standard
> grails-app/conf/DataSource.groovy file
>
> Add your database changes to the grails-app/migrations/changelog.xml
> file
>
> A starting changelog.xml is:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <databaseChangeLog
>         xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
>         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
>
> </databaseChangeLog>
>
> Full documentation on LiquiBase in general is available at
> http://www.liquibase.org.  I have yet to create any grails docs beyond
> this email :)
>
>

Hi Nathan,

Looks like great work. Would be nice if it was published to the Grails
standard repo:

http://svn.grails-plugins.codehaus.org/

I'll see if I can answer some of your questions...

>
> Some questions I have:
> 1. Does it make sense to have liquibase- appended to all the command
> names?  I was concerned that I would run into other installed plug-ins
> without them.  Is there a better way to specify them?

I dont think it is needed, even if multiple plugins have the same name
Grails will ask which one you want to run. So if you have a two
targets called  "migrate" Grails will ask which one you want to
execute.

>
> 2. The change logs are all currently XML based, which I know isn't
> particularly grails-y.  How much of a turn-off is that for everyone?
I
> plan to create a DSL version of the change log at some point, but so
far
> it hasn't been a high priority.

Yes, I think XML will be a big turn off for some, certainly if you
there was a Groovy DSL version it would attract more users. We were
looking to add this functionality to Grails after 1.0 so maybe we can
help out here or with Sam's effort (I havent had a change to evaluate
either)
>
> 3. Is there a way to use the release-plugin functionality if I don't
> host the code in your SVN repository?

Not currently. You could open the
GRAILS_HOME/scripts/ReleasePlugin.groovy file and change the pluginSVN
variable to point to your repo though. However ideally it would be
great if it was hosted in the Grails standard SVN repo.

Otherwise I guess we should think about adding functionality to make
the repos Grails looks for plugins in customisable

>
> 4. Does it make sense to have more than one database migrate plug-in
> available for Grails?  My plug-in is mainly a grails wrapper around an
> existing database migrator tool whereas Sam's seems to be more of a
> grails app from the start.  I tend to think the more options the
better,
> but it may lead to end-user confusion.

I dont think there is anything wrong with choice. However as I
mentioned we were looking to have a standardised plugin, but I will
need to evaluate what tech to base it on after 1.0

Cheers
>
> Nathan
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

graemer
Ok well if you want to put it in the main repo signup for a codehaus account

http://xircles.codehaus.org/signup

Then apply to be a plugin developer:

http://xircles.codehaus.org/projects/grails-plugins/members

Then ping me and I'll approve your access

Cheers

On 10/3/07, Nathan Voxland <[hidden email]> wrote:

> Thanks for the answers.  The reason I would like to keep it in my SVN
> repository is so that whenever anyone checks out the main liquibase
> module they will get the grails code as well.
>
> If the only way to get the plug-in in to work with list-plugins and
> install-plugin is to move the grails code to your svn, I think that is
> more important than keeping all our code together.  I'm not sure how the
> install-plugin works, but if there was a way for me to upload the built
> zip to a particular location, that would maybe work best.
>
> Nathan
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Graeme Rocher
> Sent: Wednesday, October 03, 2007 4:15 PM
> To: [hidden email]
> Subject: Re: [grails-dev] Alternative to Sam's "migrate"
>
> On 10/3/07, Nathan Voxland <[hidden email]> wrote:
> > I created an alternative to the dbmigrate-based "migrate" plugin that
> is
> > based on liquibase instead.
> >
> > It is currently available at
> > http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> > underlying engine is LiquiBase 1.3 which is production-ready.
> >
> > I had started it before Sam released his plug-in and wanted to at
> least
> > finish it up and see what everyone thought.
> >
> > The currently implanted functionality includes:
> >
> > liquibase-migrate
> > liquibase-migrateSQL
> > liquibase-tag <tag>
> > liquibase-rollback <tag>
> > liquibase-rollbackCount <num>
> > liquibase-rollbackSQL <tag>
> > liquibase-rollbackCountSQL <num>
> >
> > Set up your database using the standard
> > grails-app/conf/DataSource.groovy file
> >
> > Add your database changes to the grails-app/migrations/changelog.xml
> > file
> >
> > A starting changelog.xml is:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <databaseChangeLog
> >         xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> >         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >
> > xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> >
> > </databaseChangeLog>
> >
> > Full documentation on LiquiBase in general is available at
> > http://www.liquibase.org.  I have yet to create any grails docs beyond
> > this email :)
> >
> >
>
> Hi Nathan,
>
> Looks like great work. Would be nice if it was published to the Grails
> standard repo:
>
> http://svn.grails-plugins.codehaus.org/
>
> I'll see if I can answer some of your questions...
>
> >
> > Some questions I have:
> > 1. Does it make sense to have liquibase- appended to all the command
> > names?  I was concerned that I would run into other installed plug-ins
> > without them.  Is there a better way to specify them?
>
> I dont think it is needed, even if multiple plugins have the same name
> Grails will ask which one you want to run. So if you have a two
> targets called  "migrate" Grails will ask which one you want to
> execute.
>
> >
> > 2. The change logs are all currently XML based, which I know isn't
> > particularly grails-y.  How much of a turn-off is that for everyone?
> I
> > plan to create a DSL version of the change log at some point, but so
> far
> > it hasn't been a high priority.
>
> Yes, I think XML will be a big turn off for some, certainly if you
> there was a Groovy DSL version it would attract more users. We were
> looking to add this functionality to Grails after 1.0 so maybe we can
> help out here or with Sam's effort (I havent had a change to evaluate
> either)
> >
> > 3. Is there a way to use the release-plugin functionality if I don't
> > host the code in your SVN repository?
>
> Not currently. You could open the
> GRAILS_HOME/scripts/ReleasePlugin.groovy file and change the pluginSVN
> variable to point to your repo though. However ideally it would be
> great if it was hosted in the Grails standard SVN repo.
>
> Otherwise I guess we should think about adding functionality to make
> the repos Grails looks for plugins in customisable
>
> >
> > 4. Does it make sense to have more than one database migrate plug-in
> > available for Grails?  My plug-in is mainly a grails wrapper around an
> > existing database migrator tool whereas Sam's seems to be more of a
> > grails app from the start.  I tend to think the more options the
> better,
> > but it may lead to end-user confusion.
>
> I dont think there is anything wrong with choice. However as I
> mentioned we were looking to have a standardised plugin, but I will
> need to evaluate what tech to base it on after 1.0
>
> Cheers
> >
> > Nathan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Graeme Rocher
> Grails Project Lead
> http://grails.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

ld@ldaley.com
In reply to this post by Nathan Voxland-2

On 04/10/2007, at 7:33 AM, Nathan Voxland wrote:

> Thanks for the answers.  The reason I would like to keep it in my SVN
> repository is so that whenever anyone checks out the main liquibase
> module they will get the grails code as well.

Externals may help you here.

http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html

You could reference the plugin source via an externals definition  
from your main liquibase module. Or vice versa. That's if I am  
understanding correctly.

- LD.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: Alternative to Sam's "migrate"

Nathan Voxland-2
In reply to this post by Guillaume Laforge-2
What about the fact that there is an Eclipse plug-in as well as a
stand-alone IDE for browsing the database and making refactorings like
you would with java code (right click->refactor->create table etc.)
Using that keeps you from having to touch the XML at all.  

Does that remove a lot of the need for a DSL, or would you guys still
like one?

Nathan

-----Original Message-----
From: Guillaume Laforge [mailto:[hidden email]]
Sent: Wednesday, October 03, 2007 4:02 PM
To: [hidden email]
Subject: Re: [grails-dev] Alternative to Sam's "migrate"

Yeah, a DSL on top of their ugly XML would be easy to do I guess, even
if it's just a builder syntax on top of the XML.


On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:

> I've looked at liquibase before and the big turnoff was the XML
> changelog style, so a DSL for that part would be huge in my mind.
>
> Nice work!
>
> Jesse
>
> Sent from my iPhone
>
> On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> <[hidden email]> wrote:
>
> > I created an alternative to the dbmigrate-based "migrate" plugin
> > that is
> > based on liquibase instead.
> >
> > It is currently available at
> > http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> > underlying engine is LiquiBase 1.3 which is production-ready.
> >
> > I had started it before Sam released his plug-in and wanted to at
> > least
> > finish it up and see what everyone thought.
> >
> > The currently implanted functionality includes:
> >
> > liquibase-migrate
> > liquibase-migrateSQL
> > liquibase-tag <tag>
> > liquibase-rollback <tag>
> > liquibase-rollbackCount <num>
> > liquibase-rollbackSQL <tag>
> > liquibase-rollbackCountSQL <num>
> >
> > Set up your database using the standard
> > grails-app/conf/DataSource.groovy file
> >
> > Add your database changes to the grails-app/migrations/changelog.xml
> > file
> >
> > A starting changelog.xml is:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <databaseChangeLog
> >        xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> >        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >
> > xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> >
> > </databaseChangeLog>
> >
> > Full documentation on LiquiBase in general is available at
> > http://www.liquibase.org.  I have yet to create any grails docs
beyond
> > this email :)
> >
> >
> >
> > Some questions I have:
> > 1. Does it make sense to have liquibase- appended to all the command
> > names?  I was concerned that I would run into other installed
plug-ins

> > without them.  Is there a better way to specify them?
> >
> > 2. The change logs are all currently XML based, which I know isn't
> > particularly grails-y.  How much of a turn-off is that for
> > everyone?  I
> > plan to create a DSL version of the change log at some point, but so
> > far
> > it hasn't been a high priority.
> >
> > 3. Is there a way to use the release-plugin functionality if I don't
> > host the code in your SVN repository?
> >
> > 4. Does it make sense to have more than one database migrate plug-in
> > available for Grails?  My plug-in is mainly a grails wrapper around
an
> > existing database migrator tool whereas Sam's seems to be more of a
> > grails app from the start.  I tend to think the more options the
> > better,
> > but it may lead to end-user confusion.
> >
> > Nathan
> >
> >
---------------------------------------------------------------------

> > To unsubscribe from this list please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Jesse O'Neill-Oine
For me, having the DSL would still be far preferable to having to open another tool (I don't use Eclipse much anymore).  I usually know what changes I'm making, so just being able to specify them in a less verbose way than the XML would be killer.

-Jesse

On 10/4/07, Nathan Voxland <[hidden email]> wrote:
What about the fact that there is an Eclipse plug-in as well as a
stand-alone IDE for browsing the database and making refactorings like
you would with java code (right click->refactor->create table etc.)
Using that keeps you from having to touch the XML at all.

Does that remove a lot of the need for a DSL, or would you guys still
like one?

Nathan

-----Original Message-----
From: Guillaume Laforge [mailto:[hidden email]]
Sent: Wednesday, October 03, 2007 4:02 PM
To: [hidden email]
Subject: Re: [grails-dev] Alternative to Sam's "migrate"

Yeah, a DSL on top of their ugly XML would be easy to do I guess, even
if it's just a builder syntax on top of the XML.


On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:

> I've looked at liquibase before and the big turnoff was the XML
> changelog style, so a DSL for that part would be huge in my mind.
>
> Nice work!
>
> Jesse
>
> Sent from my iPhone
>
> On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> <[hidden email]> wrote:
>
> > I created an alternative to the dbmigrate-based "migrate" plugin
> > that is
> > based on liquibase instead.
> >
> > It is currently available at
> > http://www.liquibase.org/grails/grails-liquibase-0.9.zip.  The
> > underlying engine is LiquiBase 1.3 which is production-ready.
> >
> > I had started it before Sam released his plug-in and wanted to at
> > least
> > finish it up and see what everyone thought.
> >
> > The currently implanted functionality includes:
> >
> > liquibase-migrate
> > liquibase-migrateSQL
> > liquibase-tag <tag>
> > liquibase-rollback <tag>
> > liquibase-rollbackCount <num>
> > liquibase-rollbackSQL <tag>
> > liquibase-rollbackCountSQL <num>
> >
> > Set up your database using the standard
> > grails-app/conf/DataSource.groovy file
> >
> > Add your database changes to the grails-app/migrations/changelog.xml
> > file
> >
> > A starting changelog.xml is:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <databaseChangeLog
> >        xmlns=" http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> >        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> >
> > xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> >
> > </databaseChangeLog>
> >
> > Full documentation on LiquiBase in general is available at
> > http://www.liquibase.org.  I have yet to create any grails docs
beyond
> > this email :)
> >
> >
> >
> > Some questions I have:
> > 1. Does it make sense to have liquibase- appended to all the command
> > names?  I was concerned that I would run into other installed
plug-ins

> > without them.  Is there a better way to specify them?
> >
> > 2. The change logs are all currently XML based, which I know isn't
> > particularly grails-y.  How much of a turn-off is that for
> > everyone?  I
> > plan to create a DSL version of the change log at some point, but so
> > far
> > it hasn't been a high priority.
> >
> > 3. Is there a way to use the release-plugin functionality if I don't
> > host the code in your SVN repository?
> >
> > 4. Does it make sense to have more than one database migrate plug-in
> > available for Grails?  My plug-in is mainly a grails wrapper around
an
> > existing database migrator tool whereas Sam's seems to be more of a
> > grails app from the start.  I tend to think the more options the
> > better,
> > but it may lead to end-user confusion.
> >
> > Nathan
> >
> >
---------------------------------------------------------------------

> > To unsubscribe from this list please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email




--
----------------------------------------------------------
Jesse O'Neill-Oine // [hidden email]
Refactr LLC // http://refactr.com
mobile // 612-670-5037
----------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Dmitriy Kopylenko-3
+1 for DSL

Dmitriy.

2007/10/4, Jesse O'Neill-Oine <[hidden email]>:
For me, having the DSL would still be far preferable to having to open another tool (I don't use Eclipse much anymore).  I usually know what changes I'm making, so just being able to specify them in a less verbose way than the XML would be killer.

-Jesse


On 10/4/07, Nathan Voxland <[hidden email]> wrote:
What about the fact that there is an Eclipse plug-in as well as a
stand-alone IDE for browsing the database and making refactorings like
you would with java code (right click->refactor->create table etc.)
Using that keeps you from having to touch the XML at all.

Does that remove a lot of the need for a DSL, or would you guys still
like one?

Nathan

-----Original Message-----
From: Guillaume Laforge [mailto:[hidden email]]
Sent: Wednesday, October 03, 2007 4:02 PM
To: [hidden email]
Subject: Re: [grails-dev] Alternative to Sam's "migrate"

Yeah, a DSL on top of their ugly XML would be easy to do I guess, even
if it's just a builder syntax on top of the XML.


On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:

> I've looked at liquibase before and the big turnoff was the XML
> changelog style, so a DSL for that part would be huge in my mind.
>
> Nice work!
>
> Jesse
>
> Sent from my iPhone
>
> On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> <[hidden email]> wrote:
>
> > I created an alternative to the dbmigrate-based "migrate" plugin
> > that is
> > based on liquibase instead.
> >
> > It is currently available at
> > <a href="http://www.liquibase.org/grails/grails-liquibase-0.9.zip" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.liquibase.org/grails/grails-liquibase-0.9.zip .  The
> > underlying engine is LiquiBase 1.3 which is production-ready.
> >
> > I had started it before Sam released his plug-in and wanted to at
> > least
> > finish it up and see what everyone thought.
> >
> > The currently implanted functionality includes:
> >
> > liquibase-migrate
> > liquibase-migrateSQL
> > liquibase-tag <tag>
> > liquibase-rollback <tag>
> > liquibase-rollbackCount <num>
> > liquibase-rollbackSQL <tag>
> > liquibase-rollbackCountSQL <num>
> >
> > Set up your database using the standard
> > grails-app/conf/DataSource.groovy file
> >
> > Add your database changes to the grails-app/migrations/changelog.xml
> > file
> >
> > A starting changelog.xml is:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <databaseChangeLog
> >        xmlns=" <a href="http://www.liquibase.org/xml/ns/dbchangelog/1.3" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> >        xmlns:xsi=" <a href="http://www.w3.org/2001/XMLSchema-instance" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.w3.org/2001/XMLSchema-instance "
> >
> > xsi:schemaLocation="<a href="http://www.liquibase.org/xml/ns/dbchangelog/1.3" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > <a href="http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> >
> > </databaseChangeLog>
> >
> > Full documentation on LiquiBase in general is available at
> > <a href="http://www.liquibase.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.liquibase.org.  I have yet to create any grails docs
beyond
> > this email :)
> >
> >
> >
> > Some questions I have:
> > 1. Does it make sense to have liquibase- appended to all the command
> > names?  I was concerned that I would run into other installed
plug-ins

> > without them.  Is there a better way to specify them?
> >
> > 2. The change logs are all currently XML based, which I know isn't
> > particularly grails-y.  How much of a turn-off is that for
> > everyone?  I
> > plan to create a DSL version of the change log at some point, but so
> > far
> > it hasn't been a high priority.
> >
> > 3. Is there a way to use the release-plugin functionality if I don't
> > host the code in your SVN repository?
> >
> > 4. Does it make sense to have more than one database migrate plug-in
> > available for Grails?  My plug-in is mainly a grails wrapper around
an
> > existing database migrator tool whereas Sam's seems to be more of a
> > grails app from the start.  I tend to think the more options the
> > better,
> > but it may lead to end-user confusion.
> >
> > Nathan
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >    <a href="http://xircles.codehaus.org/manage_email" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://xircles.codehaus.org/manage_email
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     <a href="http://xircles.codehaus.org/manage_email" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
<a href="http://glaforge.free.fr/blog/groovy" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    <a href="http://xircles.codehaus.org/manage_email" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    <a href="http://xircles.codehaus.org/manage_email" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://xircles.codehaus.org/manage_email




--
----------------------------------------------------------
Jesse O'Neill-Oine // [hidden email]
Refactr LLC // <a href="http://refactr.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://refactr.com
mobile // 612-670-5037
----------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

RE: Alternative to Sam's "migrate"

Nathan Voxland-2

All right then, I’ll keep going down the DSL route.  Thanks for the feedback.

 

Nathan

 

 


From: Dmitriy Kopylenko [mailto:[hidden email]]
Sent: Friday, October 05, 2007 9:42 AM
To: [hidden email]
Subject: Re: [grails-dev] Alternative to Sam's "migrate"

 

+1 for DSL

Dmitriy.

2007/10/4, Jesse O'Neill-Oine <[hidden email]>:

For me, having the DSL would still be far preferable to having to open another tool (I don't use Eclipse much anymore).  I usually know what changes I'm making, so just being able to specify them in a less verbose way than the XML would be killer.

-Jesse

 

On 10/4/07, Nathan Voxland <[hidden email]> wrote:

What about the fact that there is an Eclipse plug-in as well as a
stand-alone IDE for browsing the database and making refactorings like
you would with java code (right click->refactor->create table etc.)
Using that keeps you from having to touch the XML at all.

Does that remove a lot of the need for a DSL, or would you guys still
like one?

Nathan

-----Original Message-----
From: Guillaume Laforge [mailto:[hidden email]]
Sent: Wednesday, October 03, 2007 4:02 PM
To: [hidden email]
Subject: Re: [grails-dev] Alternative to Sam's "migrate"

Yeah, a DSL on top of their ugly XML would be easy to do I guess, even
if it's just a builder syntax on top of the XML.


On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:
> I've looked at liquibase before and the big turnoff was the XML
> changelog style, so a DSL for that part would be huge in my mind.
>
> Nice work!
>
> Jesse
>
> Sent from my iPhone
>
> On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> <[hidden email]> wrote:
>
> > I created an alternative to the dbmigrate-based "migrate" plugin
> > that is
> > based on liquibase instead.
> >
> > It is currently available at
> > http://www.liquibase.org/grails/grails-liquibase-0.9.zip .  The
> > underlying engine is LiquiBase 1.3 which is production-ready.
> >
> > I had started it before Sam released his plug-in and wanted to at
> > least
> > finish it up and see what everyone thought.
> >
> > The currently implanted functionality includes:
> >
> > liquibase-migrate
> > liquibase-migrateSQL
> > liquibase-tag <tag>
> > liquibase-rollback <tag>
> > liquibase-rollbackCount <num>
> > liquibase-rollbackSQL <tag>
> > liquibase-rollbackCountSQL <num>
> >
> > Set up your database using the standard
> > grails-app/conf/DataSource.groovy file
> >
> > Add your database changes to the grails-app/migrations/changelog.xml
> > file
> >
> > A starting changelog.xml is:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <databaseChangeLog
> >        xmlns=" http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> >        xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
> >
> > xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> >
> > </databaseChangeLog>
> >
> > Full documentation on LiquiBase in general is available at
> > http://www.liquibase.org.  I have yet to create any grails docs
beyond
> > this email :)
> >
> >
> >
> > Some questions I have:
> > 1. Does it make sense to have liquibase- appended to all the command
> > names?  I was concerned that I would run into other installed
plug-ins
> > without them.  Is there a better way to specify them?
> >
> > 2. The change logs are all currently XML based, which I know isn't
> > particularly grails-y.  How much of a turn-off is that for
> > everyone?  I
> > plan to create a DSL version of the change log at some point, but so
> > far
> > it hasn't been a high priority.
> >
> > 3. Is there a way to use the release-plugin functionality if I don't
> > host the code in your SVN repository?
> >
> > 4. Does it make sense to have more than one database migrate plug-in
> > available for Grails?  My plug-in is mainly a grails wrapper around
an
> > existing database migrator tool whereas Sam's seems to be more of a
> > grails app from the start.  I tend to think the more options the
> > better,
> > but it may lead to end-user confusion.
> >
> > Nathan
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email





--
----------------------------------------------------------
Jesse O'Neill-Oine // [hidden email]
Refactr LLC // http://refactr.com
mobile // 612-670-5037
----------------------------------------------------------

 

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Guillaume Laforge-2
In reply to this post by Jesse O'Neill-Oine
I wouldn't be against an IntelliJ IDEA plugin though, but +1 for a DSL :-)

On 10/4/07, Jesse O'Neill-Oine <[hidden email]> wrote:

> For me, having the DSL would still be far preferable to having to open
> another tool (I don't use Eclipse much anymore).  I usually know what
> changes I'm making, so just being able to specify them in a less verbose way
> than the XML would be killer.
>
> -Jesse
>
>
> On 10/4/07, Nathan Voxland <[hidden email]> wrote:
> > What about the fact that there is an Eclipse plug-in as well as a
> > stand-alone IDE for browsing the database and making refactorings like
> > you would with java code (right click->refactor->create table etc.)
> > Using that keeps you from having to touch the XML at all.
> >
> > Does that remove a lot of the need for a DSL, or would you guys still
> > like one?
> >
> > Nathan
> >
> > -----Original Message-----
> > From: Guillaume Laforge [mailto:[hidden email] ]
> > Sent: Wednesday, October 03, 2007 4:02 PM
> > To: [hidden email]
> > Subject: Re: [grails-dev] Alternative to Sam's "migrate"
> >
> > Yeah, a DSL on top of their ugly XML would be easy to do I guess, even
> > if it's just a builder syntax on top of the XML.
> >
> >
> > On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:
> > > I've looked at liquibase before and the big turnoff was the XML
> > > changelog style, so a DSL for that part would be huge in my mind.
> > >
> > > Nice work!
> > >
> > > Jesse
> > >
> > > Sent from my iPhone
> > >
> > > On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> > > <[hidden email]> wrote:
> > >
> > > > I created an alternative to the dbmigrate-based "migrate" plugin
> > > > that is
> > > > based on liquibase instead.
> > > >
> > > > It is currently available at
> > > >
> http://www.liquibase.org/grails/grails-liquibase-0.9.zip.
>  The
> > > > underlying engine is LiquiBase 1.3 which is production-ready.
> > > >
> > > > I had started it before Sam released his plug-in and wanted to at
> > > > least
> > > > finish it up and see what everyone thought.
> > > >
> > > > The currently implanted functionality includes:
> > > >
> > > > liquibase-migrate
> > > > liquibase-migrateSQL
> > > > liquibase-tag <tag>
> > > > liquibase-rollback <tag>
> > > > liquibase-rollbackCount <num>
> > > > liquibase-rollbackSQL <tag>
> > > > liquibase-rollbackCountSQL <num>
> > > >
> > > > Set up your database using the standard
> > > > grails-app/conf/DataSource.groovy file
> > > >
> > > > Add your database changes to the
> grails-app/migrations/changelog.xml
> > > > file
> > > >
> > > > A starting changelog.xml is:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > >
> > > > <databaseChangeLog
> > > >        xmlns="
> http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> > > >
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > > >
> > > >
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > > >
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> > > >
> > > > </databaseChangeLog>
> > > >
> > > > Full documentation on LiquiBase in general is available at
> > > > http://www.liquibase.org.  I have yet to create any grails docs
> > beyond
> > > > this email :)
> > > >
> > > >
> > > >
> > > > Some questions I have:
> > > > 1. Does it make sense to have liquibase- appended to all the command
> > > > names?  I was concerned that I would run into other installed
> > plug-ins
> > > > without them.  Is there a better way to specify them?
> > > >
> > > > 2. The change logs are all currently XML based, which I know isn't
> > > > particularly grails-y.  How much of a turn-off is that for
> > > > everyone?  I
> > > > plan to create a DSL version of the change log at some point, but so
> > > > far
> > > > it hasn't been a high priority.
> > > >
> > > > 3. Is there a way to use the release-plugin functionality if I don't
> > > > host the code in your SVN repository?
> > > >
> > > > 4. Does it make sense to have more than one database migrate plug-in
> > > > available for Grails?  My plug-in is mainly a grails wrapper around
> > an
> > > > existing database migrator tool whereas Sam's seems to be more of a
> > > > grails app from the start.  I tend to think the more options the
> > > > better,
> > > > but it may lead to end-user confusion.
> > > >
> > > > Nathan
> > > >
> > > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >    http://xircles.codehaus.org/manage_email
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
> > --
> > Guillaume Laforge
> > Groovy Project Manager
> > http://glaforge.free.fr/blog/groovy
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
>
> --
> ----------------------------------------------------------
> Jesse O'Neill-Oine // [hidden email]
> Refactr LLC // http://refactr.com
> mobile // 612-670-5037
> ----------------------------------------------------------


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Guillaume Laforge-2
In reply to this post by Nathan Voxland-2
Out of curiosity, do you work on Liquibase? (committer/contributer?)


On 10/5/07, Nathan Voxland <[hidden email]> wrote:

>
>
>
>
> All right then, I'll keep going down the DSL route.  Thanks for the
> feedback.
>
>
>
> Nathan
>
>
>
>
>
>  ________________________________
>
>
> From: Dmitriy Kopylenko [mailto:[hidden email]]
>  Sent: Friday, October 05, 2007 9:42 AM
>
>  To: [hidden email]
>  Subject: Re: [grails-dev] Alternative to Sam's "migrate"
>
>
>
>
> +1 for DSL
>
>  Dmitriy.
>
>
> 2007/10/4, Jesse O'Neill-Oine <[hidden email]>:
>
> For me, having the DSL would still be far preferable to having to open
> another tool (I don't use Eclipse much anymore).  I usually know what
> changes I'm making, so just being able to specify them in a less verbose way
> than the XML would be killer.
>
>  -Jesse
>
>
>
>
>
> On 10/4/07, Nathan Voxland < [hidden email]> wrote:
>
> What about the fact that there is an Eclipse plug-in as well as a
>  stand-alone IDE for browsing the database and making refactorings like
>  you would with java code (right click->refactor->create table etc.)
>  Using that keeps you from having to touch the XML at all.
>
>  Does that remove a lot of the need for a DSL, or would you guys still
>  like one?
>
>  Nathan
>
>  -----Original Message-----
>  From: Guillaume Laforge [mailto: [hidden email] ]
>  Sent: Wednesday, October 03, 2007 4:02 PM
>  To: [hidden email]
>  Subject: Re: [grails-dev] Alternative to Sam's "migrate"
>
>  Yeah, a DSL on top of their ugly XML would be easy to do I guess, even
>  if it's just a builder syntax on top of the XML.
>
>
>  On 10/3/07, Jesse O'Neill-Oine <[hidden email] > wrote:
>  > I've looked at liquibase before and the big turnoff was the XML
>  > changelog style, so a DSL for that part would be huge in my mind.
>  >
>  > Nice work!
>  >
>  > Jesse
>  >
>  > Sent from my iPhone
>  >
>  > On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
>  > <[hidden email]> wrote:
>  >
>  > > I created an alternative to the dbmigrate-based "migrate" plugin
>  > > that is
>  > > based on liquibase instead.
>  > >
>  > > It is currently available at
>  > >
> http://www.liquibase.org/grails/grails-liquibase-0.9.zip
> .  The
>  > > underlying engine is LiquiBase 1.3 which is production-ready.
>  > >
>  > > I had started it before Sam released his plug-in and wanted to at
>  > > least
>  > > finish it up and see what everyone thought.
>  > >
>  > > The currently implanted functionality includes:
>  > >
>  > > liquibase-migrate
>  > > liquibase-migrateSQL
>  > > liquibase-tag <tag>
>  > > liquibase-rollback <tag>
>  > > liquibase-rollbackCount <num>
>  > > liquibase-rollbackSQL <tag>
>  > > liquibase-rollbackCountSQL <num>
>  > >
>  > > Set up your database using the standard
>  > > grails-app/conf/DataSource.groovy file
>  > >
>  > > Add your database changes to the
> grails-app/migrations/changelog.xml
>  > > file
>  > >
>  > > A starting changelog.xml is:
>  > >
>  > > <?xml version="1.0" encoding="UTF-8"?>
>  > >
>  > > <databaseChangeLog
>  > >        xmlns="
> http://www.liquibase.org/xml/ns/dbchangelog/1.3"
>  > >        xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance "
>  > >
>  > >
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
>  > >
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
>  > >
>  > > </databaseChangeLog>
>  > >
>  > > Full documentation on LiquiBase in general is available at
>  > > http://www.liquibase.org.  I have yet to create any grails docs
>  beyond
>  > > this email :)
>  > >
>  > >
>  > >
>  > > Some questions I have:
>  > > 1. Does it make sense to have liquibase- appended to all the command
>  > > names?  I was concerned that I would run into other installed
>  plug-ins
>  > > without them.  Is there a better way to specify them?
>  > >
>  > > 2. The change logs are all currently XML based, which I know isn't
>  > > particularly grails-y.  How much of a turn-off is that for
>  > > everyone?  I
>  > > plan to create a DSL version of the change log at some point, but so
>  > > far
>  > > it hasn't been a high priority.
>  > >
>  > > 3. Is there a way to use the release-plugin functionality if I don't
>  > > host the code in your SVN repository?
>  > >
>  > > 4. Does it make sense to have more than one database migrate plug-in
>  > > available for Grails?  My plug-in is mainly a grails wrapper around
>  an
>  > > existing database migrator tool whereas Sam's seems to be more of a
>  > > grails app from the start.  I tend to think the more options the
>  > > better,
>  > > but it may lead to end-user confusion.
>  > >
>  > > Nathan
>  > >
>  > >
> ---------------------------------------------------------------------
>  > > To unsubscribe from this list please visit:
>  > >
>  > >    http://xircles.codehaus.org/manage_email
>  > >
>  >
>  >
> ---------------------------------------------------------------------
>  > To unsubscribe from this list please visit:
>  >
>  >     http://xircles.codehaus.org/manage_email
>  >
>  >
>
>
>  --
>  Guillaume Laforge
>  Groovy Project Manager
>  http://glaforge.free.fr/blog/groovy
>
> ---------------------------------------------------------------------
>  To unsubscribe from this list please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
>  To unsubscribe from this list please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>
>
>
>
>
> --
>  ----------------------------------------------------------
>  Jesse O'Neill-Oine // [hidden email]
>  Refactr LLC // http://refactr.com
>  mobile // 612-670-5037
>  ----------------------------------------------------------
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: Alternative to Sam's "migrate"

Nathan Voxland-2
In reply to this post by Guillaume Laforge-2
Actually I am working on an IntellJ plugin as well.  I'm a native
IntelliJ user, but I created the Eclipse plug-in first because Eclipse's
rich client platform lets me create a stand-alone IDE easily.  Getting
back to Intellij is a breath of fresh air :)  The IntelliJ plugin will
hopefully have an initial version available in a couple weeks.

I do work on LiquiBase in general as well as a committer.  

Nathan

-----Original Message-----
From: Guillaume Laforge [mailto:[hidden email]]
Sent: Friday, October 05, 2007 9:50 AM
To: [hidden email]
Subject: Re: [grails-dev] Alternative to Sam's "migrate"

I wouldn't be against an IntelliJ IDEA plugin though, but +1 for a DSL
:-)

On 10/4/07, Jesse O'Neill-Oine <[hidden email]> wrote:
> For me, having the DSL would still be far preferable to having to open
> another tool (I don't use Eclipse much anymore).  I usually know what
> changes I'm making, so just being able to specify them in a less
verbose way
> than the XML would be killer.
>
> -Jesse
>
>
> On 10/4/07, Nathan Voxland <[hidden email]> wrote:
> > What about the fact that there is an Eclipse plug-in as well as a
> > stand-alone IDE for browsing the database and making refactorings
like
> > you would with java code (right click->refactor->create table etc.)
> > Using that keeps you from having to touch the XML at all.
> >
> > Does that remove a lot of the need for a DSL, or would you guys
still

> > like one?
> >
> > Nathan
> >
> > -----Original Message-----
> > From: Guillaume Laforge [mailto:[hidden email] ]
> > Sent: Wednesday, October 03, 2007 4:02 PM
> > To: [hidden email]
> > Subject: Re: [grails-dev] Alternative to Sam's "migrate"
> >
> > Yeah, a DSL on top of their ugly XML would be easy to do I guess,
even

> > if it's just a builder syntax on top of the XML.
> >
> >
> > On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:
> > > I've looked at liquibase before and the big turnoff was the XML
> > > changelog style, so a DSL for that part would be huge in my mind.
> > >
> > > Nice work!
> > >
> > > Jesse
> > >
> > > Sent from my iPhone
> > >
> > > On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> > > <[hidden email]> wrote:
> > >
> > > > I created an alternative to the dbmigrate-based "migrate" plugin
> > > > that is
> > > > based on liquibase instead.
> > > >
> > > > It is currently available at
> > > >
> http://www.liquibase.org/grails/grails-liquibase-0.9.zip.
>  The
> > > > underlying engine is LiquiBase 1.3 which is production-ready.
> > > >
> > > > I had started it before Sam released his plug-in and wanted to
at

> > > > least
> > > > finish it up and see what everyone thought.
> > > >
> > > > The currently implanted functionality includes:
> > > >
> > > > liquibase-migrate
> > > > liquibase-migrateSQL
> > > > liquibase-tag <tag>
> > > > liquibase-rollback <tag>
> > > > liquibase-rollbackCount <num>
> > > > liquibase-rollbackSQL <tag>
> > > > liquibase-rollbackCountSQL <num>
> > > >
> > > > Set up your database using the standard
> > > > grails-app/conf/DataSource.groovy file
> > > >
> > > > Add your database changes to the
> grails-app/migrations/changelog.xml
> > > > file
> > > >
> > > > A starting changelog.xml is:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > >
> > > > <databaseChangeLog
> > > >        xmlns="
> http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> > > >
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > > >
> > > >
> xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > > >
> http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> > > >
> > > > </databaseChangeLog>
> > > >
> > > > Full documentation on LiquiBase in general is available at
> > > > http://www.liquibase.org.  I have yet to create any grails docs
> > beyond
> > > > this email :)
> > > >
> > > >
> > > >
> > > > Some questions I have:
> > > > 1. Does it make sense to have liquibase- appended to all the
command
> > > > names?  I was concerned that I would run into other installed
> > plug-ins
> > > > without them.  Is there a better way to specify them?
> > > >
> > > > 2. The change logs are all currently XML based, which I know
isn't
> > > > particularly grails-y.  How much of a turn-off is that for
> > > > everyone?  I
> > > > plan to create a DSL version of the change log at some point,
but so
> > > > far
> > > > it hasn't been a high priority.
> > > >
> > > > 3. Is there a way to use the release-plugin functionality if I
don't
> > > > host the code in your SVN repository?
> > > >
> > > > 4. Does it make sense to have more than one database migrate
plug-in
> > > > available for Grails?  My plug-in is mainly a grails wrapper
around
> > an
> > > > existing database migrator tool whereas Sam's seems to be more
of a

> > > > grails app from the start.  I tend to think the more options the
> > > > better,
> > > > but it may lead to end-user confusion.
> > > >
> > > > Nathan
> > > >
> > > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >    http://xircles.codehaus.org/manage_email
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
> > --
> > Guillaume Laforge
> > Groovy Project Manager
> > http://glaforge.free.fr/blog/groovy
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
>
> --
> ----------------------------------------------------------
> Jesse O'Neill-Oine // [hidden email]
> Refactr LLC // http://refactr.com
> mobile // 612-670-5037
> ----------------------------------------------------------


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Alternative to Sam's "migrate"

Guillaume Laforge-2
On 10/5/07, Nathan Voxland <[hidden email]> wrote:
> Actually I am working on an IntellJ plugin as well.  I'm a native
> IntelliJ user, but I created the Eclipse plug-in first because Eclipse's
> rich client platform lets me create a stand-alone IDE easily.  Getting
> back to Intellij is a breath of fresh air :)  The IntelliJ plugin will
> hopefully have an initial version available in a couple weeks.

Hooray :-)

> I do work on LiquiBase in general as well as a committer.

Excellent!
I've eyed Liquibase but never came to try it so far, and it looks pretty cool.
Good job!

> -----Original Message-----
> From: Guillaume Laforge [mailto:[hidden email]]
> Sent: Friday, October 05, 2007 9:50 AM
> To: [hidden email]
> Subject: Re: [grails-dev] Alternative to Sam's "migrate"
>
> I wouldn't be against an IntelliJ IDEA plugin though, but +1 for a DSL
> :-)
>
> On 10/4/07, Jesse O'Neill-Oine <[hidden email]> wrote:
> > For me, having the DSL would still be far preferable to having to open
> > another tool (I don't use Eclipse much anymore).  I usually know what
> > changes I'm making, so just being able to specify them in a less
> verbose way
> > than the XML would be killer.
> >
> > -Jesse
> >
> >
> > On 10/4/07, Nathan Voxland <[hidden email]> wrote:
> > > What about the fact that there is an Eclipse plug-in as well as a
> > > stand-alone IDE for browsing the database and making refactorings
> like
> > > you would with java code (right click->refactor->create table etc.)
> > > Using that keeps you from having to touch the XML at all.
> > >
> > > Does that remove a lot of the need for a DSL, or would you guys
> still
> > > like one?
> > >
> > > Nathan
> > >
> > > -----Original Message-----
> > > From: Guillaume Laforge [mailto:[hidden email] ]
> > > Sent: Wednesday, October 03, 2007 4:02 PM
> > > To: [hidden email]
> > > Subject: Re: [grails-dev] Alternative to Sam's "migrate"
> > >
> > > Yeah, a DSL on top of their ugly XML would be easy to do I guess,
> even
> > > if it's just a builder syntax on top of the XML.
> > >
> > >
> > > On 10/3/07, Jesse O'Neill-Oine <[hidden email]> wrote:
> > > > I've looked at liquibase before and the big turnoff was the XML
> > > > changelog style, so a DSL for that part would be huge in my mind.
> > > >
> > > > Nice work!
> > > >
> > > > Jesse
> > > >
> > > > Sent from my iPhone
> > > >
> > > > On Oct 3, 2007, at 2:48 PM, "Nathan Voxland"
> > > > <[hidden email]> wrote:
> > > >
> > > > > I created an alternative to the dbmigrate-based "migrate" plugin
> > > > > that is
> > > > > based on liquibase instead.
> > > > >
> > > > > It is currently available at
> > > > >
> > http://www.liquibase.org/grails/grails-liquibase-0.9.zip.
> >  The
> > > > > underlying engine is LiquiBase 1.3 which is production-ready.
> > > > >
> > > > > I had started it before Sam released his plug-in and wanted to
> at
> > > > > least
> > > > > finish it up and see what everyone thought.
> > > > >
> > > > > The currently implanted functionality includes:
> > > > >
> > > > > liquibase-migrate
> > > > > liquibase-migrateSQL
> > > > > liquibase-tag <tag>
> > > > > liquibase-rollback <tag>
> > > > > liquibase-rollbackCount <num>
> > > > > liquibase-rollbackSQL <tag>
> > > > > liquibase-rollbackCountSQL <num>
> > > > >
> > > > > Set up your database using the standard
> > > > > grails-app/conf/DataSource.groovy file
> > > > >
> > > > > Add your database changes to the
> > grails-app/migrations/changelog.xml
> > > > > file
> > > > >
> > > > > A starting changelog.xml is:
> > > > >
> > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > >
> > > > > <databaseChangeLog
> > > > >        xmlns="
> > http://www.liquibase.org/xml/ns/dbchangelog/1.3"
> > > > >
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > > > >
> > > > >
> > xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.3
> > > > >
> > http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.3.xsd">
> > > > >
> > > > > </databaseChangeLog>
> > > > >
> > > > > Full documentation on LiquiBase in general is available at
> > > > > http://www.liquibase.org.  I have yet to create any grails docs
> > > beyond
> > > > > this email :)
> > > > >
> > > > >
> > > > >
> > > > > Some questions I have:
> > > > > 1. Does it make sense to have liquibase- appended to all the
> command
> > > > > names?  I was concerned that I would run into other installed
> > > plug-ins
> > > > > without them.  Is there a better way to specify them?
> > > > >
> > > > > 2. The change logs are all currently XML based, which I know
> isn't
> > > > > particularly grails-y.  How much of a turn-off is that for
> > > > > everyone?  I
> > > > > plan to create a DSL version of the change log at some point,
> but so
> > > > > far
> > > > > it hasn't been a high priority.
> > > > >
> > > > > 3. Is there a way to use the release-plugin functionality if I
> don't
> > > > > host the code in your SVN repository?
> > > > >
> > > > > 4. Does it make sense to have more than one database migrate
> plug-in
> > > > > available for Grails?  My plug-in is mainly a grails wrapper
> around
> > > an
> > > > > existing database migrator tool whereas Sam's seems to be more
> of a
> > > > > grails app from the start.  I tend to think the more options the
> > > > > better,
> > > > > but it may lead to end-user confusion.
> > > > >
> > > > > Nathan
> > > > >
> > > > >
> > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list please visit:
> > > > >
> > > > >    http://xircles.codehaus.org/manage_email
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >     http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > >
> > >
> > > --
> > > Guillaume Laforge
> > > Groovy Project Manager
> > > http://glaforge.free.fr/blog/groovy
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
> >
> > --
> > ----------------------------------------------------------
> > Jesse O'Neill-Oine // [hidden email]
> > Refactr LLC // http://refactr.com
> > mobile // 612-670-5037
> > ----------------------------------------------------------
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email