Hi This actually sounds quite possible (with a few provisos and caveats)
You can set the storage name for the table easily, and there is no requirement that they're unique enforced in the DataMapper code. There's also no requirement in DataMapper that a model maps all the columns in the table, so for reading it should definitely work fine. You do have to make sure each of the models has its own primary key, but DataMapper does support natural and also composite primary keys. For writing to the tables, I'm less sure. I think this will depend more on the constraints/defaults the table has. I'm not 100% sure how DataMapper will cope with generating the joins and such, but I think it should. I've never heard someone try this before, but nothing leaps out as an immediate show-stopper. Regards Jon On 25 September 2010 01:26, gw <[email protected]> wrote: > 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.
