The other day I accidentally ran into a “gotcha” that I quickly realized any one of us might have current production code that has eliminated records in a grid display. This could be occurring without even realizing the problem. When dealing with large record sets, not even testing departments take time to review every record to insure data is 100% accurate. After all, production needs to be out and testing department checks operation not counts as would be expected.
The problem occurs in the model definition. The model has a config idProperty that is defaulted to
We do have the flexibility to change the default to something else.
If you have a union query returning data. The best example I can think of is customers and business customers. We would often keep these two types of customers in different tables and do a union when presenting the data to administrators in a single table, removing the additional step of either two tabs or combo box to represent the two different types of customers.
Event making the change of the idProperty does not eliminate what happens if there are two records having the same value specified in idProperty.
Per documentation on the model:
Ext JS documentation for the model A Model definition always has an identifying field which should yield a unique key for each instance. By default, a field named "id" will be created with a mapping of "id". This happens because of the default idProperty provided in Model definitions.
Key is is “should” yield a unique key. The documentation needs to phrase it as
idProperty is treated as a unique identifier and all duplicates will be lost. Only the last record with the duplicate idProperty will be displayed in the grid.
I inadvertently created dummy data using copy/paste and didn’t change the id value so all records had id: 1. It was only 10 records so the gotcha was easily discovered when I found only the last record appeared in the grid. When checking the number of records in the store using store.length, the length was 10, yet only one displayed.
Now digging deeper into the documentation for idProperty:
The data values for this field must be unique or there will be id value collisions in the Ext.data.Store.
Now we get information regrading “collisions” in the store. But “collisions” doesn’t get defined. To me, this isn’t clear enough and should indicate data may/could/is lost and not displayed.
Ext JS doesn’t support complex keys so how does one solve this problem? Can we find a way to code into our project an all around solution that could solve these potential problems. We don’t really have a choice as the fiddle found at:
show, this doesn’t work and is a problem.
Ext JS is a good framework as I do use it for all my current projects and at my day job. As programmers though we need to write more of these gotcha’s so others can see limitations and what they need to do in order to work around the problem.
One solution to this gotcha is when pulling data, assign your unique id to something like recId. Then leave the default idProperty: ‘id’ set without changing it. Define recId in your model and then handle it in your server side code to do your updates from recId and not id. The recId will be sent in CRUD applications and the idProperty can be left for Ext JS to handle how it so desires as you won’t be using it on the backend to accomplish your goals.