Cheers Dan - and thanks for the SQL::Abstract nod! Seems alot of us old-school Perl hackers have made the move to Ruby. :-)
It took a look at the README for SQLA to remember you sent me a few patches back when. Once the DM standard migration code gets ironed out, maybe I can help you/Matt with some auto-upgrade tweaks to return the favor. -Nate On Jun 2, 7:46 am, Tony Mann <thephatm...@gmail.com> wrote: > 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) <dan.k...@gmail.com>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_migrationsThat 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 datamap...@googlegroups.com. > > To unsubscribe from this group, send email to > > datamapper+unsubscr...@googlegroups.com<datamapper%2bunsubscr...@googlegrou > > ps.com> > > . > > 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 datamap...@googlegroups.com. To unsubscribe from this group, send email to datamapper+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
