1. #1
    Sencha User
    Join Date
    Nov 2008
    Location
    Lyon, France
    Posts
    215
    Vote Rating
    5
    christophe.geiser will become famous soon enough

      0  

    Default 4.2.0Beta: Ext.data.Model, id management consistency

    4.2.0Beta: Ext.data.Model, id management consistency


    Hi all,

    Thanks for the 4.2.0 beta release.

    I have seen that id management has undergone significant changes compared to 4.1 version. It is not that I am against any improvement over the releases, on the contrary. But honestly, I cannot remember how many time such a fundamental feature has changed over time since the first release of the Ext 4 family.

    What I would wish - before the final release of 4.2 - is a clear and well thought-through documentation on data.Model id generation (model.internalId, model.id, model.data.id) and the implication it has on other properties of the model (phantom in particular).

    I know I can get this from the code itself, but I hope 4.2 is mature enough to make us developer feel confident that 4.3 and beyond will not yet again handle core features like this one in a different way.

    Thanks,
    C.

  2. #2
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,505
    Vote Rating
    53
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    I agree that it needs to be consistent.

    What he have now is:

    internalId is automatically assigned and never changes. It's what's used by SelectionModels so that when a new (phantom) record is added, and then synced with the server and acquires a real ID, the selection model still recognizes it as selected. The internalID never gets updated.

    data.id will only be present if you leave the idProperty at its default of "id".

    A model Field is created to encapsulate the idProperty. It's name is the idProperty value, and its mapping is too. So that obviously creates a data.<whatever> property.

    In 4.2, the idProperty config may be a full Field configuration with mapping and name configs.

    It may also have a convert config so that it can generate an identifier by aggregating and calculating based on other fields.

    The identifying field is used as the value from getId()

    I don't think model.id (the getObservableId) property is used for anything. I will ask the team and see if it can be removed.

  3. #3
    Sencha User
    Join Date
    Nov 2008
    Location
    Lyon, France
    Posts
    215
    Vote Rating
    5
    christophe.geiser will become famous soon enough

      0  

    Default


    Thanks a lot for this detailed answer !

    The way I see this for the moment - and that was the reason for the post - is that I do not have the impression this part of the code is solid enough. I know it is a beta and beta are ... beta. But if this part is changed - let us be sure that it is once for good and for all ; )

    For instance:
    - internalId should be unique (according to the doc). If this is the case, why on earth derive it from passed arguments when id is set on construction. This can only lead to id clash.
    - What is/are the criteria to decide if a record is phantom or not - it is not crystal obvious from the code.
    - Is it really necessary to have an id() and a setId() method ? both modifying phantom property?
    - what is the real added value of hasId() ?
    - as for model.id - if it is not used otherwise, yes please remove it.
    Cheers,
    C.

    Quote Originally Posted by Animal View Post
    I agree that it needs to be consistent.

    What he have now is:

    internalId is automatically assigned and never changes. It's what's used by SelectionModels so that when a new (phantom) record is added, and then synced with the server and acquires a real ID, the selection model still recognizes it as selected. The internalID never gets updated.

    data.id will only be present if you leave the idProperty at its default of "id".

    A model Field is created to encapsulate the idProperty. It's name is the idProperty value, and its mapping is too. So that obviously creates a data.<whatever> property.

    In 4.2, the idProperty config may be a full Field configuration with mapping and name configs.

    It may also have a convert config so that it can generate an identifier by aggregating and calculating based on other fields.

    The identifying field is used as the value from getId()

    I don't think model.id (the getObservableId) property is used for anything. I will ask the team and see if it can be removed.

  4. #4
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,505
    Vote Rating
    53
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    internalId is generated.

    phantom property is cleared when the record gets a server-assigned ID. That is a real ID - the field configured to be the ID field.

Thread Participants: 1