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 <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 10:50 AM, Shane Witbeck > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > >> On Tue, Sep 9, 2008 at 6:56 AM, Shane Witbeck <[EMAIL PROTECTED] > > > >> 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 > >> > > >> > > >
