PDA

View Full Version : [DUP] [Bug] Update a model record resets attributes with persist: false



netzpirat
9 Aug 2011, 11:08 AM
REQUIRED INFORMATION


Ext version tested:

Ext 4.0.5
Browser versions tested against:

Chrome 13.0.782.112
Description:

I have a model with non-persisted attributes. Now when I update a persist-able attribute and save the record, then the non-persisted attribute values are reset to their default values.
Steps to reproduce the problem:

TestModel.load(1, { success: function(testModel) { window.testModel = testModel }});
testModel.get('test'); // null
testModel.get('another'); // Hello
testModel.set('test', 'Some info');
testModel.set('another', 'Goodbye');
testModel.save()
testModel.get('test'); // Some info
testModel.get('another'); // Hello
The result that was expected:

In the example testModel.get('another'); should return 'Goodbye'.
The result that occurs instead:

The value was reset to its default value 'Hello'.
Test Case:



Ext.define('TestModel', {
extend: 'Ext.data.Model',

fields: [
{ name: 'test', type: 'string', defaultValue: null },
{ name: 'another', type: 'string', defaultValue: 'Hello', persist: false }
],

proxy: {
type: 'rest',
url: '/echo',
reader: {
type: 'json',
root: 'data'
},
writer: {
type: 'json',
root: 'test'
}
}
});


HELPFUL INFORMATION


Screenshot or Video:

none
Debugging already done:

The problem is that the non-persisted fields are not excluded when updating the client record from the server record in Operation.js
Possible fix:

I added a filter that removes any undefined or non-persisted fields.


From b3deedfe91f0f18f2f21790a2bae858f3cfa72dd Mon Sep 17 00:00:00 2001
From: Michael Kessler <michi@netzpiraten.ch>
Date: Tue, 9 Aug 2011 21:05:45 +0200
Subject: [PATCH] Only update persisted attributes on the client record.


---
public/lib/ext4/src/data/Operation.js | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)


diff --git a/public/lib/ext4/src/data/Operation.js b/public/lib/ext4/src/data/Operation.js
index 31c8f85..f204b4f 100644
--- a/public/lib/ext4/src/data/Operation.js
+++ b/public/lib/ext4/src/data/Operation.js
@@ -182,6 +182,12 @@ Ext.define('Ext.data.Operation', {

if (clientRec) {
clientRec.beginEdit();
+ // Don't update fields that are not persisted fields
+ Ext.Object.each(serverRec.data, function(key, value, data) {
+ if (!clientRec.fields.containsKey(key) || !clientRec.fields.get(key).persist) {
+ delete data[key];
+ }
+ });
clientRec.set(serverRec.data);
clientRec.endEdit(true);
}
--
1.7.6




Additional CSS used:

only default ext-all.css
Operating System:

Mac OS X 10.7

netzpirat
15 Aug 2011, 11:32 AM
Is there something missing or unclear in this bug report? I'm a paying customer who spent some time in debugging your product and filing an appropriate bug report, and Sencha is ignoring me completely! That just feels wrong.

ykey
3 Oct 2011, 7:17 PM
Bump. Ran into this today. Is this expected behavior?

evant
3 Oct 2011, 10:04 PM
Not really clear on what the issue is here, specifically, what are the responses from the server for load/save?

netzpirat
4 Oct 2011, 12:54 AM
Wow, someone from Sencha is joining the party! Quite late for a bug report that has been filed almost two month ago.

If you would study the Bug Report then you would understand what the issue is. There is a description of the problem, expected result and an explanation of the outcome, with code, steps to reproduce and even a patch. The response does not include the reseted attributes, because they are not persist and frontend only.

I don't care about a solution from Sencha anymore. I switched the framework because Sencha is so lazy and ignores its developers.

evant
4 Oct 2011, 1:35 AM
I don't see why this is an issue. I'm assuming you're sending back a value for the 'another' field after you call save. I think it's a totally reasonable behaviour for it to update the value. The documentation doesn't say that the value won't be updated on the client, rather:



False to exclude this field from the Ext.data.Model.modified fields in a model. This will also exclude the field from being written using a Ext.data.writer.Writer. This option is useful when model fields are used to keep state on the client but do not need to be persisted to the server.


A save is essentially a load, except you also pass the data to update the data on the server. When you send the info back, it gets updated on the record.

ykey
4 Oct 2011, 11:49 AM
This option is useful when model fields are used to keep state on the client but do not need to be persisted to the server.

I am using model fields with persist false to keep state on the client that do not need to be persisted to the server. When I save those model instances those client fields are being blanked because the server does not know about them, clearing the client state. I do not see how this would be expected behavior.

ykey
4 Oct 2011, 11:59 AM
Pseudo-code



Ext.define('User', {
extend: 'Ext.data.Model',
fields: [
'name',
{ name: 'lastAction', persist: false }
]
});


var user = Ext.create('User', {
id: '1',
name: 'ykey',
lastAction: 'action-id'
});


user.save();


HTTP PUT - { id: '1', name: 'ykey' }
Response - { id: '1', name: 'ykey' } // Server does not know about lastAction


user.get('lastAction') // null