On Dec 22, 2008, at 12:33 PM, Dan Kubb (dkubb) wrote: > The option that I am leaning towards right now is to deprecate > belongs_to and make it so you can define a property() that references > the other model. So instead of this: > > class Order > # ... > > belongs_to :customer > end > > You could write: > > class Order > # ... > > property :customer, Customer > end > > So the usage of a Model as the property type would create the customer > accessor/mutator (which is exactly what happens anyway for a type), > but it would also create whatever child keys you need underneath. Any > options passed to property() would be passed down to the child keys on > creation, allowing you to specify nullability, indexes, etc. I think > this reads quite naturally, and so far everyone I've shown it to > thinks it is pretty easy to understand.
That sounds pretty cool Dan. I'm still a little uneasy with being able to specify :nullable => false on the belongs_to property. If you also constrain the has side (maybe with a has 1), then you could have chicken and egg problems, i.e., one side must exist in the table before the other side can pass valid? but with both sides are requiring the other to exist and be associated before the record can be saved. Constraining belongs_to could also increase the complexity of fixtures. Thank you, Roy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
