We use autoupgrade all the time on our medium-size project, since almost all of our db modifications involve adding fields. It is tremendously useful -- we have not yet written a single migration! Sometimes we have to tweak the db by hand, but this is so rare that it is not a problem. Since autoupgrade has never caused data loss, I would in fact recommend using it, as long as you understand its limitations. It is one of my favorite parts of DM.
..tony.. On Tue, Jun 1, 2010 at 11:32 PM, Dan Kubb (dkubb) <[email protected]>wrote: > Nate, > > > > > 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. > > Ahh yes. This is similar to what I had planned for auto-migrations in > DM. At the moment the auto-migration and with the "classic migration" > code is not very DRY. We'll be rebuilding the classic migrations API, > and then making auto-migrations and auto-upgrading use the same > interfaces rather than implementing their own logic. Part of the > reason for the duplication is that up until recently the logic for > both was in different packages; but we unified them to help make > further improvements. > > One of the plans is to have it so that we can use the model state to > compare against the DB state, and either apply the migration > immediately or create a classic migration that you can tweak if you > want. It should be possible to remove the need to ever write classic > migrations by hand again, we should be able to infer everything from > the models which IMHO is even better than what this plugin does. > > > 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). > > I can understand your point of view. I think it depends on what you > can live with. In some cases, if you understand the scope of the > problem you can design a schema that doesn't change very frequently. > In other cases you have very little information up-front and the > schema can change drastically as your understanding grows. In the > latter case I think at some point if you had alot of aliases built up > you might want to deprecate the aliases and remove the extra mapping > layer from your design. > > I know in the case of some classes I write with little up-front > knowledge I am continuously refactoring with "Rename Method", and I > know that I would only want to maintain aliases for as little time as > possible. If they were part of my private API, I would want to change > those names immediately without aliasing anything. For public methods > I would only want to keep aliases, with deprecations, around until the > next major release. > > > 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. > > I think a smarter auto-upgrade is very important too. I just don't > think our current implementation is anything I would recommend at the > moment. If it was able to make changes to the schema based on the > current model structure it would be something I would recommend alot > more often to people. > > > Thanks again for the clarifications on DM's expected > > behavior; sounds like our existing toolset is a better fit. > > No problem. If you have a good toolset that you're comfortable with, I > think that's awesome. I'm sure that when we get auto-upgrade > "upgraded" Matt will let you know so you can take another look at > it ;) > > -- > > Dan > (dkubb) > > P.S. Thanks for SQL::Abstract. Back in the day I wrote alot of perl/ > DBI code with your lib. > > -- > 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]<datamapper%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/datamapper?hl=en. > > -- 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.
