Thanks for the clarifications. Sounds like it was a misunderstanding on my part.
FWIW, we actually use the ActiveRecord auto_migrations plugin by pjhyett in Production for all migrations and it works awesome: http://github.com/pjhyett/auto_migrations That plugin handles modifications/deletes of existing columns, such as changing sizes, removing null contraints, etc. As you said, auto-upgrading can't handle renaming columns, but you shouldn't be changing column names after the fact IMO. If you chose a bad name, add an alias in the model, or just get over it. If you live with this minor restriction, then your life gets infinitely easier across the board (eg at the controller/view level too). But I realize my team is in the minority, which is unfortunate for the community as a whole because auto-migrations are really amazing. There's no way we could survive without them given how fast we have to develop. Thanks again for the clarifications on DM's expected behavior; sounds like our existing toolset is a better fit. Cheers, Nate Wiger PlayStation On Jun 1, 12:10 am, "Dan Kubb (dkubb)" <[email protected]> wrote: > Nate, > > > I've been experimenting with DM 1.0.0.rc3 and auto-migrations don't > > appear to be working as expected. Specifically, it appears that > > modifications to columns are not reflected in the DB if the columns > > already exist. > > This is actually by design. The auto-upgrade feature is only > *additive*, in that it will add things that don't exist, but it will > not change anything that is present. So it adds new tables and > columns, but does not change any columns that are present. > > There will be some work after 1.0 to make auto-upgrading a bit > smarter, but up until now we've been conservative in what it does. > Anytime to loosen a constraint it should be fairly easy to make the > change. In some cases it might even be possible to tighten constraints > if we inspect the data beforehand. (for example, changing CHAR(20) to > CHAR(10) might be possible as long as SELECT MAX(LENGTH(col)) is <= > 10) The reason we've avoided this up until now is that it can get > complex quickly, and even a tiny mistake on our end may cause a data > loss. If we do approach this in the future it will have to be > extremely well specced and tested before we'll release it to the > public. > > At the moment though I personally don't see auto-upgrading as being > very useful, since there will always be things it can't handle > automatically like renames and deletions. For me it's more a question > between auto-migrating (which is destructive) and classic migrations. > > -- > > Dan -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
