PDA

View Full Version : 1.1.1 broke store.sync for modified records



yoorek
3 Nov 2011, 1:31 PM
Since 1.1.1 store.sync() stopped work for records modified with record.set(fieldname, value);

After store.sync() nothing happens though record.save() works!!!

I looked at Ext.util.Stateful.set method code in 1.1.0 and it is changed drastically in 1.1.1.

In 1.1.0 set method changes dirty flag with 1 line:


this.dirty = true

In 1.1.1 set motkd changes dirty flag after checking conditions which are never true.
First - field.persist ?? ok, I set it in model (why?) but then currentValue is undefined at raises error.

Here is code in 1.1.1 that replaced one above line in 1.1.0:


if (field && field.persist && !me.isEqual(currentValue, value)) {
if (me.isModified(fieldName)) {
if (me.isEqual(modified[fieldName], value)) {


delete modified[fieldName];


me.dirty = false;
for (key in modified) {
if (modified.hasOwnProperty(key)){
me.dirty = true;
break;
}
}
}
} else {
me.dirty = true;
modified[fieldName] = currentValue;
}
}



After reverting to 1.1.0 everything works OK.

What is the cause of such a "improvement" in crucial method ?

Möhre
4 Nov 2011, 12:41 AM
Beginner question: What´s the consequence of this bug?

Does it mean that records that have been modified with record.set(fieldname, value) in 1.1.0 are gone in 1.1.1?

yoorek
4 Nov 2011, 12:47 AM
Yes.

In 1.1.0:


record.set('NAME', 'NewName');
store.sync(); // UPDATE GOES TO STORAGE
record.set('NAME', 'NewName2');
record.save(); // UPDATE GOES TO STORAGE

In 1.1.1


record.set('NAME', 'NewName');
store.sync(); // NOTHING HAPPENS, USER CLOSES APP AND CHANGES ARE LOST
record.set('NAME', 'NewName2');
record.save(); // UPDATE GOES TO STORAGE

MiamiCoder
10 Nov 2011, 5:22 AM
I can reproduce this problem as well.

MiamiCoder
10 Nov 2011, 5:23 AM
I've been able to work around this in some scenarios with a call to setDirty on the model immediately before the sync call on the store.

Möhre
12 Nov 2011, 8:04 AM
Thanks, setDirty does the trick.

Wow, you already updated your tutorial/blog. Fast guy ;)

Why does Sencha not have a complete unit testcase to avoid such bugs???

urk
7 Dec 2011, 5:52 AM
Hi,

This override works for me (don't worry about the number of lines, actually it's just two edited lines and an additional small function taken from the Sencha Touch 2 Developer Preview):


if (Ext.version == '1.1.1') {

// fix: modified records are not marked as dirty and therefore ignored on store sync
Ext.override(Ext.util.Stateful, {

/**
* Sets the given field to the given value, marks the instance as dirty
* @param {String|Object} fieldName The field to set, or an object containing key/value pairs
* @param {Mixed} value The value to set
*/
set: function(fieldName, value) {
var me = this,
fields = me.fields,
modified = me.modified,
convertFields = [],
field, key, i;

/*
* If we're passed an object, iterate over that object. NOTE: we pull out fields with a convert function and
* set those last so that all other possible data is set before the convert function is called
*/
if (arguments.length == 1 && Ext.isObject(fieldName)) {
for (key in fieldName) {
if (!fieldName.hasOwnProperty(key)) {
continue;
}

//here we check for the custom convert function. Note that if a field doesn't have a convert function,
//we default it to its type's convert function, so we have to check that here. This feels rather dirty.
field = fields.get(key);
if (field && field.convert !== field.type.convert) {
convertFields.push(key);
continue;
}

me.set(key, fieldName[key]);
}

for (i = 0; i < convertFields.length; i++) {
field = convertFields[i];
me.set(field, fieldName[field]);
}

} else {
if (fields) {
field = fields.get(fieldName);

if (field && field.convert) {
value = field.convert(value, me);
}
}
// *** added line ***
currentValue = me.get(fieldName);
me[me.persistanceProperty][fieldName] = value;

// *** edited line *** if (field && field.persist && !me.isEqual(currentValue, value)) {
if (!me.isEqual(currentValue, value)) {
if (me.isModified(fieldName)) {
if (me.isEqual(modified[fieldName], value)) {
// the original value in me.modified equals the new value, so the
// field is no longer modified
delete modified[fieldName];
// we might have removed the last modified field, so check to see if
// there are any modified fields remaining and correct me.dirty:
me.dirty = false;
for (key in modified) {
if (modified.hasOwnProperty(key)){
me.dirty = true;
break;
}
}
}
} else {
me.dirty = true;
modified[fieldName] = currentValue;
}
}

// fix
me.dirty = true;

if (!me.editing) {
me.afterEdit();
}
}
},

// *** added function ***
/**
* Checks if two values are equal, taking into account certain
* special factors, for example dates.
* @private
* @param {Object} a The first value
* @param {Object} b The second value
* @return {Boolean} True if the values are equal
*/
isEqual: function(a, b){
if (Ext.isDate(a) && Ext.isDate(b)) {
return a.getTime() === b.getTime();
}
return a === b;
}

});

};

Cheers,

Uwe

yoorek
7 Dec 2011, 9:21 AM
Thanks for the code.

Actually I got my own solution - got rid of Sencha Touch.
This kind of mistakes makes me sure ST is not ready for production - it seams they don't have QA at all.
There are to many hacks and workarounds - spent 90% of time debugging framework and 10% developing application. Waste of time.
Will give another try in year or two. Maybe.

karthiktheraja
15 Dec 2011, 11:48 AM
I am also facing the same problem with sencha touch 1.1.1 , I tried with loadData(data, false),which removes existing data and adds new data in sencha touch 1.1.0 is not working with sencha 1.1.1 . I want to know whether this bug will be rectified in next version or any work around is needed .I am working with local storage .Please give your suggestion.Thanks

yoorek
15 Dec 2011, 12:10 PM
My solution is to get rid off Sencha. I Lost 6 months with this kind of bugs. There are dozens of bugs older than six months. Breaking absolutely crucial part of data access with minor upgrade is embarassing - and nobody cares working on 2.0 that maybe in 1 year will be ready for production.
Truth is we were tricked by Sencha - we thought that Alfa version of their product is ready to use because they named it 1.1.

JacobGu
16 Dec 2011, 8:38 AM
The bug is definitely in Ext.util.Stateful's set method. It changed significantly from 1.1.0.

Möhre
17 Dec 2011, 2:35 AM
I am also facing the same problem with sencha touch 1.1.1 , I tried with loadData(data, false),which removes existing data and adds new data in sencha touch 1.1.0 is not working with sencha 1.1.1 . I want to know whether this bug will be rectified in next version or any work around is needed .I am working with local storage .Please give your suggestion.Thanks

I don´t think there will be an 1.1.x update cause sencha is concentrating on bringing out 2.0. But Sencha may clarify this.

ST 2.0 is no option at this point of time cause PR3 still has problems with local storage, just read the bug forum.

jep
10 Feb 2012, 8:26 PM
Ugh. I ran into this, too. It's staggering that Sencha hasn't replied to the original post given that it started in November. I've been sorely disappointed in the QA of the releases at Sencha as well. We've yet to ever get a branch that's reasonably stable and bug free. I'm not even talking about minor bugs but huge showstopping bugs like these. And then they just blithely moved onto 2.0 and I feel like we're ready to start on the same treadmill again until they abandon the still buggy 2.x for shiny new 3.0.

And someone asked do they not do unit tests to detect these kind of obvious problems. Maybe they do, and maybe their unit tests are buggy. Or maybe they're just not very complete. It's been kind of brutal, being a programmer coming from a world where such things are basic to web development where it's all flying by the seat of your pants and just hoping you remember to write perfect code. It really is an impoverished world. The sad thing is that ST is one of the better ones in this regard from what I've seen. What does that say about the state of the others?

yoorek
11 Feb 2012, 1:43 AM
I have to agree with every word you wrote. This bug shows how QA and support in Sencha works. They broke code with 1.1.1 and didn't evet care to fix it. Because of this "bugs-hacking-to-achieve-simple-things" nightmare my client cancelled whole project last september and I lost a lot of time and money.
I think the biggest mistake made by Sencha was announcing ST as version 1.0 - it should be "preview" or "alpha" and nobody would be hurt by terrible quality of it. The second biggest mistake was ignoring all bug requests for months. Although I think ST is the best framework in town my trust to Sencha is gone for ever.
I must admit that I check from time to time quality of ST2 and I think it finally looks promising - but is it going to be stable and worth working with it ? - we need to wait another year for it. Still - I would go without seconds thought for another similar product because I just don't like Sencha as a company.
I hoped that some big company will take care of web mobile applications and build framework that will have proffessional quality (stable, documented, supported) not like Sencha or jQuery "open source" type.
And it actually happened - I'm looking forward to test HP Enyo 2.0 when it will become available - it looks very promising and with background of HP it can be real killer.