22 Aug 2014 11:10 AM #11
Be aware that this means the child record has no way to identify its parent and so saving could be a bit more complex. You might have to use code like this:
22 Aug 2014 11:32 AM #12
One reason this is appealing is that it gives you a complete definition of your data model in one place. Obviously your call on that but I've done in the past and the consolidated place for the "M" layer was quite helpful.
In the end, hasMany is still supported and can be the right answer in your particular case. That said, see my previous comment about save when there is no key field to relate records.
23 Aug 2014 5:21 AM #13
thanks for taking the time to answer. Please forgive me lack of knowledge (or understanding), but I still don't get why it's desirable to declare the relation on the child rather than on the parent.
24 Aug 2014 3:16 PM #14
In the most general sense, I don't think there is a "best" place to declare an association between two entities. It could go either way... but one entity must be made aware of the other.
Where it gets practical is when you have to communicate with a server or database. In many cases the server's API determines what you have to do on the client and you base model configuration on those requirements.
From a green-field perspective, however, consider a simple data model such Customer, Order and OrderItem. The storage of these records in a traditional table form would typically use "foreign keys" to link an OrderItem to its Order (for example "orderId") and to link an Order to the Customer ("customerId").
This is the kind of thing a "reference" field describes. This representation allows you to fetch the Customer for an Order or even change the association of an Order record to a different Customer by setting the "customerId" and saving the record.
Getting back to the practical - if your server sends nested records and no key fields there is little reason to switch to "reference" fields on your models. The hasMany config is a valid way to describe such associations but it is just limited. You cannot fetch a Customer from an Order, for example, because there is no field on the Order to hold the Customer's id. This likewise makes changing the associated Customer problematic since there is no customerId field to set.
But if those operations are not supported by your server anyway or perhaps are handled differently, there is no point in worrying about it.
If you have more specific questions, it would probably help to better understand your server and what it sends to and understands from the client.
25 Aug 2014 10:32 AM #15
Thank you for your explanation to all these hasMany vs. reference questions. I was also curious to know what limits reference from resolving a "many" association without a foreign key and without a child model being aware of its parent model, but your answer clarifies it for my original question and that works for me.