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]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
