1. #11
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,365
    Answers
    25
    Vote Rating
    135
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      0  

    Default


    @andreas-spindler -

    Quote Originally Posted by andreas-spindler View Post
    But, this also means, if I want to use my E-Mail model by more than one "parent", I have to add a reference for each single "owning" model. E.g. an E-Mail can be part of a "Company", but in my mail client it is also a part of the models "Folder" and "Follow". So, taking your example from above, the E-Mail model would look like this (?):
    Code:
    Ext.define('Email', {
        extend: 'Ext.data.Model',
        fields: ['id', 'subject', 'content', {
            name: 'companyId',
            reference: 'Company'
        },{
            name: 'folderId',
            reference: 'Folder'
        },{
            name: 'followId',
            reference: Follow
        }]
    });
    That is correct. In v4 you had to specify the association on both sides (unless you didn't care about one of them). If your models simply don't have these fields, then hasMany is as good as anything. If you do have these fields (as many systems do) than declaring them and their associated type is not a big deal.

    Quote Originally Posted by andreas-spindler View Post
    This means, that the E-Mail model has to know of all the owning models. If I want to do it the other way round, so the "owner models" are the only ones aware of their child-models, there is only the "hasMany" association left?
    Yes, "hasMany" is used to declare "key-less" associations.

    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:

    Code:
    company.getData(true)
    This will get all the child associations (and then some). Or roll your own form of a "nested save". It will depend on the needs of your server.
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  2. #12
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,365
    Answers
    25
    Vote Rating
    135
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      0  

    Default


    @araad -

    Quote Originally Posted by araad View Post
    In my case, even if I supplied the foreign keys from the server in order to use a reference field instead of hasMany, it would still not work for me.

    Lets say for example that I have many packages, with one common package that is required by all others.

    The common package contains the Email model, the company package contains the Company model and so on. That would mean I would have to require "common" in "company" and vice versa, wouldn't that cause a circular dependency when building?
    You don't need to require models in order to use them in a reference field. That would typically create a situation where all the models would be pulled in to a build due to the transitivity of it all.

    Quote Originally Posted by araad View Post
    Even if, somehow, I don't need to require the other packages in the common one (e.g.: model types can be resolved at run-time) or no circular dependency occurs during the build, that means the common package would still have to be aware of the other packages in order to define each foreign key for all associations.

    Using hasMany works well for my case, but it would be nice to use the reference field in the same way without a child model being aware of its parent models, just like in the case of one-to-one.
    You could think of it a different way: having a "model package". The build process will only include the models you need from that package (by virtue of "requires").

    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.
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  3. #13
    Sencha User
    Join Date
    Aug 2012
    Posts
    87
    Answers
    2
    Vote Rating
    7
    andreas-spindler is on a distinguished road

      0  

    Default


    Hi Don,

    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.

  4. #14
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,365
    Answers
    25
    Vote Rating
    135
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      1  

    Default


    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.
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  5. #15
    Sencha User
    Join Date
    Apr 2014
    Posts
    16
    Vote Rating
    3
    araad is on a distinguished road

      0  

    Default


    Hi Don,

    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.

    Thanks,
    Amer