AndyV | 16 May 20:55

Re: Combine old migrations?


<rant>
@Ryan, Do you ever stop to consider that people have very good reasons
to do things that you might not do?  I'm getting tired of seeing
responses like "Gee I wouldn't do that" or "it's dumb to have that
javascript turned off" or ...  It'd be a lot more helpful, if you're
that enlightened, if you would both explain how to do it AND SUGGEST
why it is not considered a good idea.

That said, consider this.  One site that I'm working on currently has
150+ migrations for about 120 tables.  By your logic I'd be dumb to
combine them.  But it's quite possible that this app will be deployed
both publicly (hosting for small customers) and privately (intranet
for very large customers).  I'm perfectly willing to keep creating
migrations when necessary for the public side, but if I am doing a
fresh install on a private site, what sense does it make to deploy the
20-30 migrations that are patched and overridden by later ones?
Wouldn't a single, clean migration script serve those customers much
better?
</rant>

@Stedwick -- rake db:schema:dump should give you pretty much what
you're looking for.  I'll let you discern from the previous comments
whether or not YOU think it's a good idea. :)

Cheers.

On May 15, 9:31 pm, "Ryan Bigg (Radar)" <radarliste...@...>
wrote:
> Not a good idea.
>
> If you think 20 is a bad number I'd hate to see if you'd work on a big
> project (100+ migrations)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---


Gmane