suggestion for new feature: db migrations

[Shane Witbeck <sh...@digitalsanctum.com>]

DB migrations as part of the build/deploy process via Buildr:

http://code.google.com/p/c5-db-migration/

What do you think?


-Shane

Re: suggestion for new feature: db migrations

[Shane Witbeck <sh...@digitalsanctum.com>]

Rhett,

Thanks for the link. Having different dialects seems like a definite must
have to keep it flexible for different db's. I haven't taken a close look at
either yet and I'm sure there are more existing solutions out there. Just
thought I'd voice the idea here before to see what others thought before I
dedicated more time to this.

We have a need for something like this internally and we're already using
Buildr soo...

-Shane


On Tue, Sep 9, 2008 at 10:56 AM, Rhett Sutphin <rh...@detailedbalance.net>wrote:

> Hi Shane,
>
>
> On Sep 9, 2008, at 8:56 AM, Shane Witbeck wrote:
>
>  DB migrations as part of the build/deploy process via Buildr:
>>
>> http://code.google.com/p/c5-db-migration/
>>
>> What do you think?
>>
>
> FWIW, I wrote (with some colleagues) a database migration system called
> bering.  I mention it because it has an ant task, so you can use it with
> buildr with no changes.
>
> http://code.google.com/p/bering
>
> It's more specifically a port of rails' ActiveRecord migrations, so the
> implementation is a bit different from Carbon Five's.  In particular, it
> uses a groovy DSL backed by a hibernate-like dialect system (instead of
> plain SQL scripts) to support multiple databases.  (It was developed for use
> with a suite of clinical research applications which support either
> PostgreSQL or Oracle.)
>
> Deployment-wise, bering includes a ServletContextListener that can
> automatically apply new migrations on application startup.
>
> End plug.
>
> Rhett
>

Re: suggestion for new feature: db migrations

[Rhett Sutphin <rh...@detailedbalance.net>]

Hi Shane,

On Sep 9, 2008, at 8:56 AM, Shane Witbeck wrote:

> DB migrations as part of the build/deploy process via Buildr:
>
> http://code.google.com/p/c5-db-migration/
>
> What do you think?

FWIW, I wrote (with some colleagues) a database migration system  
called bering.  I mention it because it has an ant task, so you can  
use it with buildr with no changes.

http://code.google.com/p/bering

It's more specifically a port of rails' ActiveRecord migrations, so  
the implementation is a bit different from Carbon Five's.  In  
particular, it uses a groovy DSL backed by a hibernate-like dialect  
system (instead of plain SQL scripts) to support multiple databases.   
(It was developed for use with a suite of clinical research  
applications which support either PostgreSQL or Oracle.)

Deployment-wise, bering includes a ServletContextListener that can  
automatically apply new migrations on application startup.

End plug.

Rhett

Re: suggestion for new feature: db migrations

[Assaf Arkin <ar...@intalio.com>]

Apropos, here's the Rails guide for using migrations. Might have some
good ideas:
http://guides.rails.info/migrations/migrations.html

Assaf

On Thu, Sep 11, 2008 at 7:57 AM, Shane Witbeck <sh...@digitalsanctum.com> wrote:
> Provide the framework for doing arbitrary database operations (SQL) via a
> jdbc driver? The addons would do the same arbitrary tasks via a specific ORM
> framework although not sure how useful ORM is in this context.
>
> Maybe an intitial step would be creating an arbitrary sql task that could
> then be called before and/or after a deploy task or integration test task. I
> attribute this to the SQL Ant task.
>
> A later step would be something closer to true migrations similar to how RoR
> handles them. Associate 1 to n sql tasks to a versioned project complete
> with rollback capability.
>
> -Shane
>
>
> On Wed, Sep 10, 2008 at 11:29 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
>> On Wed, Sep 10, 2008 at 10:50 AM, Shane Witbeck
>> <sh...@digitalsanctum.com> wrote:
>> > My answer to these types of questions is always to let the user decide or
>> in
>> > this case let them develop the addons. When I first proposed this I was
>> > actually just thinking about a SQL-only solution.
>>
>> So what should Buildr role be?  Provide one default set of migration
>> tasks?  Specify how the tasks are used, but not implement any?
>>
>> Assaf
>>
>> >
>> > -Shane
>> >
>> >
>> > On Wed, Sep 10, 2008 at 12:58 PM, Assaf Arkin <ar...@intalio.com> wrote:
>> >
>> >> On Tue, Sep 9, 2008 at 6:56 AM, Shane Witbeck <shane@digitalsanctum.com
>> >
>> >> wrote:
>> >> > DB migrations as part of the build/deploy process via Buildr:
>> >> >
>> >> > http://code.google.com/p/c5-db-migration/
>> >> >
>> >> > What do you think?
>> >>
>> >> Yes.
>> >>
>> >> It sounds to me like all migration solutions are nearly the same when
>> >> you're changing schemas around.  But then you need to populate a
>> >> table, generate fake data, or shift data around, and now it's a
>> >> question of how to run non-SQL code and which language and ORM you
>> >> favor.
>> >>
>> >> Do we want to pick, or just have people develop different addons?
>> >>
>> >> Assaf
>> >>
>> >> >
>> >> >
>> >> > -Shane
>> >> >
>> >>
>> >
>>
>

Re: suggestion for new feature: db migrations

[Shane Witbeck <sh...@digitalsanctum.com>]

Provide the framework for doing arbitrary database operations (SQL) via a
jdbc driver? The addons would do the same arbitrary tasks via a specific ORM
framework although not sure how useful ORM is in this context.

Maybe an intitial step would be creating an arbitrary sql task that could
then be called before and/or after a deploy task or integration test task. I
attribute this to the SQL Ant task.

A later step would be something closer to true migrations similar to how RoR
handles them. Associate 1 to n sql tasks to a versioned project complete
with rollback capability.

-Shane


On Wed, Sep 10, 2008 at 11:29 PM, Assaf Arkin <ar...@intalio.com> wrote:

> On Wed, Sep 10, 2008 at 10:50 AM, Shane Witbeck
> <sh...@digitalsanctum.com> wrote:
> > My answer to these types of questions is always to let the user decide or
> in
> > this case let them develop the addons. When I first proposed this I was
> > actually just thinking about a SQL-only solution.
>
> So what should Buildr role be?  Provide one default set of migration
> tasks?  Specify how the tasks are used, but not implement any?
>
> Assaf
>
> >
> > -Shane
> >
> >
> > On Wed, Sep 10, 2008 at 12:58 PM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> >> On Tue, Sep 9, 2008 at 6:56 AM, Shane Witbeck <shane@digitalsanctum.com
> >
> >> wrote:
> >> > DB migrations as part of the build/deploy process via Buildr:
> >> >
> >> > http://code.google.com/p/c5-db-migration/
> >> >
> >> > What do you think?
> >>
> >> Yes.
> >>
> >> It sounds to me like all migration solutions are nearly the same when
> >> you're changing schemas around.  But then you need to populate a
> >> table, generate fake data, or shift data around, and now it's a
> >> question of how to run non-SQL code and which language and ORM you
> >> favor.
> >>
> >> Do we want to pick, or just have people develop different addons?
> >>
> >> Assaf
> >>
> >> >
> >> >
> >> > -Shane
> >> >
> >>
> >
>

Re: suggestion for new feature: db migrations

[Assaf Arkin <ar...@intalio.com>]

On Wed, Sep 10, 2008 at 10:50 AM, Shane Witbeck
<sh...@digitalsanctum.com> wrote:
> My answer to these types of questions is always to let the user decide or in
> this case let them develop the addons. When I first proposed this I was
> actually just thinking about a SQL-only solution.

So what should Buildr role be?  Provide one default set of migration
tasks?  Specify how the tasks are used, but not implement any?

Assaf

>
> -Shane
>
>
> On Wed, Sep 10, 2008 at 12:58 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
>> On Tue, Sep 9, 2008 at 6:56 AM, Shane Witbeck <sh...@digitalsanctum.com>
>> wrote:
>> > DB migrations as part of the build/deploy process via Buildr:
>> >
>> > http://code.google.com/p/c5-db-migration/
>> >
>> > What do you think?
>>
>> Yes.
>>
>> It sounds to me like all migration solutions are nearly the same when
>> you're changing schemas around.  But then you need to populate a
>> table, generate fake data, or shift data around, and now it's a
>> question of how to run non-SQL code and which language and ORM you
>> favor.
>>
>> Do we want to pick, or just have people develop different addons?
>>
>> Assaf
>>
>> >
>> >
>> > -Shane
>> >
>>
>

Re: suggestion for new feature: db migrations

[Shane Witbeck <sh...@digitalsanctum.com>]

My answer to these types of questions is always to let the user decide or in
this case let them develop the addons. When I first proposed this I was
actually just thinking about a SQL-only solution.

-Shane


On Wed, Sep 10, 2008 at 12:58 PM, Assaf Arkin <ar...@intalio.com> wrote:

> On Tue, Sep 9, 2008 at 6:56 AM, Shane Witbeck <sh...@digitalsanctum.com>
> wrote:
> > DB migrations as part of the build/deploy process via Buildr:
> >
> > http://code.google.com/p/c5-db-migration/
> >
> > What do you think?
>
> Yes.
>
> It sounds to me like all migration solutions are nearly the same when
> you're changing schemas around.  But then you need to populate a
> table, generate fake data, or shift data around, and now it's a
> question of how to run non-SQL code and which language and ORM you
> favor.
>
> Do we want to pick, or just have people develop different addons?
>
> Assaf
>
> >
> >
> > -Shane
> >
>

Re: suggestion for new feature: db migrations

[Assaf Arkin <ar...@intalio.com>]

On Tue, Sep 9, 2008 at 6:56 AM, Shane Witbeck <sh...@digitalsanctum.com> wrote:
> DB migrations as part of the build/deploy process via Buildr:
>
> http://code.google.com/p/c5-db-migration/
>
> What do you think?

Yes.

It sounds to me like all migration solutions are nearly the same when
you're changing schemas around.  But then you need to populate a
table, generate fake data, or shift data around, and now it's a
question of how to run non-SQL code and which language and ORM you
favor.

Do we want to pick, or just have people develop different addons?

Assaf

>
>
> -Shane
>