On 10-07-22 9:04 AM, Koen Deforche wrote:
> Hey Sohail,
>
> 2010/7/19 Sohail Somani<[email protected]>:
>> I was doing something similar before when I would hand write my SQL. I
>> guess I'll still be doing that! I heard the Ruby people have some sort
>> of tool that helps them migrate the schemas.
>>
>> Here is the Ruby thing I was thinking of:
>>
>> http://www.oracle.com/technology/pub/articles/kern-rails-migrations.html
>>
>> I do something similar to what you do when I hand-write my SQL. Perhaps
>> it is possible to define a mini-framework for data migration.
>
> I like the Rails approach to migrations -- I think something like this
> for Wt::Dbo would be really nice, as an alternative to createTables()
> / dropTables().
>
> The one thing to realize is that the migrations feature of Rails is
> entirely separate from the actual ORM: there is nothing in Ruby's
> migration framework that somehow maintains consistency between the
> migrations and the schema used by the ORM. As such, a good schema
> migration tool could and should be not connected to a particular ORM
> framework at all, and if were not because of SQL dialects, it could
> just as well be done in SQL.
>
> The three features you need for a migration framework are (IMHO):
>   - defining a schema version which can be stored as well in the
> database (and that's easy)
>   - choosing an API in which upgrade and downgrade scripts are
> specified, preferably something that has a syntax that is either known
> or easy familiarized with (that's the creative part)
>   - implementing a small tool that applies different migrations
> sequentially, to upgrade or downgrade (that's easy too)
>
> Perhaps someone has a good idea/experience with an existing solution?

My experience with migrations was with cl-migrations which was pretty 
good but used SQL directly and had the dialect problems.

Simple migrations are easy. Tricky are hard. That's probably why  most 
tools stick to SQL. IIRC, if you want to add a constraint onto a SQLite 
column, you have to create a temporary table, insert all the old data 
into it, drop the old table, create a new table with the new constraint 
and insert from the temporary table. Wt itself does not have the API to 
do this so it would be inventing a new database management API.

One thing I think is also important is the ability to embed the 
migrations into your application logic. Upgrading/downgrading the schema 
should be a function call.

Finally, I think Wt will likely get more help with Dbo and projects like 
this if you use the Boost license. That community is looking for a good 
ORM and in my humble opinion, Wt's Dbo is the best one for C++.

Hiberlite was GPL but it has recently switched to BSD.

Sohail


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to