[Rails] Re: Generating SQL from model and not vice versa

[Dave Ringoen]

I'm totally fine with the approach of modifying the schema in a SQL tool
like CocoaMySQL. My issue is how to keep the development db and the
production db in sync. What I've been doing lately is to modify my
development db with CocoaMySQL, then cutting and pasting the appropriate
ALTER TABLE and CREATE TABLE statements from the CocoaMySQL log into a SQL
script I later use on the existing production db when I release the code
into production. Does anyone have a more automated way of doing this for
MySQL? Perhaps by "diffing" the development and production schemas, and
producing a delta SQL script to update the production schema? I've searched
the web and found SQL schema diffing tools for MS SQL Server for example,
but not much for MySQL.

Sorry if this is a bit off-topic, but it's got me thinking since everybody
is adding up all the clicks in their guis and editor keystrokes. This is
definitely an area that requires a bit of bookkeeping.

Dave


On 3/1/05 3:24 AM, "David Heinemeier Hansson" <david at loudthinking.com>
wrote:

>>> Is it only to avoid switching to a tool specially designed for such
>>> tasks and doing it with a few clicks/
>> 
>> Few clicks?  Hardly.  Either way I have to type the table/class name,
>> field/attribute names, data types, and associations.  No savings on
>> typing either way, but one less conceptual shift if everything is
>> driven by code.
> 
> Have you seen the Rails videos? There was a new one just released that
> shows the flow once again. When you make the changes straight on the
> database, you don't have a build phase (generate SQL from model, drop
> database, create new database), which means its change'n'reload to see
> result.
> 
> And, as I described in the earlier example, you don't throw out the
> data you've been working on to make a change. Which is the most
> important benefit to me.
> 
> But the discussion is no longer an either or. Since I'm going to do the
> migration approach anyway, having the possibility of an in-model schema
> is a fairly trivial addition. And one that'll benefit those who don't
> like to leave their editor while working a system or those who needs
> the benefits of 1 abstract schema => 6 concrete schemas.
> --
> David Heinemeier Hansson,
> http://www.basecamphq.com/   -- Web-based Project Management
> http://www.rubyonrails.org/  -- Web-application framework for Ruby
> http://www.loudthinking.com/ -- Broadcasting Brain
> 
> _______________________________________________
> Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>