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.

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.

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.

Originally Posted by Animal

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.