Luke, On Feb 16, 4:16 pm, Luke Galea <ldga...@gmail.com> wrote: > Thanks everyone. I'll go through all my commit logs and pull out all > the changes I had to make so at least that can make it's way into dm- > migrations some day and we'll post to the list about the issue that's > stopping us now.
I was attempting to fix a older bug last night in dm-migrations and I ran into alot of other issues with things being untested and code just being wrong. I was actually going to suggest that we consider updating dm-migrations or rewriting it before DM 1.0 is released. Part of the DM 1.0 Roadmap (http://wiki.github.com/datamapper/dm-core/ roadmap) is to extract the migration code from dm-core, which is extremely well tested, and move it into shared libs that dm-migration can use. The dm-migrations DSL is decent, so I'd probably keep most of it except where it diverges slightly with the dm-core's property declaration API.. where I'd deprecate the old behaviour in favour of being consistent with dm-core. Having the same code used for "classic" migrations and "auto" migrations will be more likely to ensure this sort of thing doesn't happen. Another idea I had was possibly pushing migrations down a layer to become a DO plugin (the first real one). We'd need four libraries to duplicate our current functionality: 1) A library that knows how to reflect on the DB structure and create objects to represent the tables/columns/indexes in their current state 2) A library to carry out table/column/index creation and modification 3) A library to know how to use the reflection API, and then use the modification layer to bring the DB to a specific state 4) A library to act as a thin shim between dm-core, #2 and #3 for auto-migrate and auto-upgrade As I said all of this functionality exists, but it exists in a non- modular form (i.e. it's scattered between dm-core, and dm-migrations right now). I even thought about collapsing some of these into a CRUD- type library, where you'd have table/column/index objects that you could modify, and they'd keep track of their old and new state, and then when you ask them to persist themselves they take care of issuing the correct DDL statements on the DB. If anyone has any suggestions or input on this I'd be interested in hearing it. This might be something we push for DM 2.0, but it's something worth thinking about as I know classic migrations are painful for some people. -- Dan (dkubb) -- 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.
