-
They getKey of the MixedCollection is just an injected function which returns this.internalId
So the key is how the internalId of the Record is set.
Look for this code in the reader:"
Code:
extractData : function(root) {
var me = this,
records = [],
Model = me.model,
length = root.length,
clientIdProp = Model.prototype.clientIdProperty,
fields = me.getFields(),
fieldLength = fields.length,
convertedValue, convertedValues, field, name, node, id, record, i, j, value;
if (!root.length && Ext.isObject(root)) {
root = [root];
length = 1;
}
for (i = 0; i < length; i++) {
node = root[i];
id = me.getId(node);
// Create a record with an empty data object.
// Populate that data object by extracting and converting field values from raw data
record = new Model(undefined, id, node, convertedValues = {});
And see if you can step into there in the Readers you are testing.
-
The line in the extractData method of Ext.data.reader.Reader
id = me.getId(node);
is in fact returning the correct numbers, in my case (1,2,5) so the problem must be occurring higher up the tree, I will being going up the stack and try and locate it.
-
Ok I'v located the problem code, however I have no idea what it's purpose is.
I forgot to include the a portion of the data being returned.... sorry about that.
Inside of the Readers extractData method there is this code
Code:
if (node[clientIdProp]) {
record.internalId = node[clientIdProp];
}
My data set returned has 2 ids, a projectId and a clientId (1 client many projects). initially the internalId is set correctly based on the idProperty value however once it passes over that code, it sees that there is also a 'clientId'?? property on the node and then updates it to that... Which happens to be the same for each of my models being returned because I'm returning a list of data associated with a client...
Removing that property from the json data being returned fixes the issue.
-
It seems like this property is used internally to track batch changes in the writer. However this seems like a fairly common field name, is there any chance you can rename it to something a little more obscure?
-
That would be a good idea. I have transferred this ticket to the engineer who implemented the clientId property. We will come up with a fix for 4.1.0 final.
-
Ah, excellent!
Skirtle sent me here for a look... glad to see it's being picked up!
I hit the issue and reported it in the beta forum, but didn't get much traction...
For what it's worth, my base model sets the clientIdProperty to 'phantomId', since I believe that's what it's intended for?
Cheers,
Westy
-
This is fixed post-RC1 (just now merged). The clientIdProperty will default to null.
