Hi, First, thanks for DataMapper. I did my own "mostly" DM pattern in another language some years ago and prefer it conceptually over AR, but haven't had the need in Rails to push me to investigate the Ruby gem deeply. Now I do.
My case is largely driven by legacy data. A non-trivial application with multiple databases, over 250 combined tables and about 2GB of data. The current app code is not OO, and the tables have been defined more to suit dbm philosophies than oop philosophies. As a result, some of these tables have quite a lot of fields. From a Rails/AR perspective, many of these tables should be broken apart with more 1:1 associations. Now the app code is being converted to Rails. Well, part of the app code. There's multiple apps sharing the data, and we have to leave the schema 99.9% alone. I need to develop a reasonable roadmap for evolving the system from today's schema to a more OO/Rails/ ORM idiomatic schema. Sorry, long lead up to... I'm wondering if DataMapper's more explicit declarations of attributes/ fields can be leveraged to create many smaller models, each which refers to the same db table, but with a unique set of defined attributes/fields. If DM can do that, I see that as a way to get better OO/Rails idioms into the app code (using DM's attribute aliasing, lazy loading, and mapping) to define better data model's in the app code, but allow us to change the actual schema after all the old app code has been replaced. At that time we can change the schema to be more isomorphic with the class models. Is it possible/does it make sense to use DataMapper in this way? Applogies for being long winded. Thanks! -- 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.
