[3.4.0] Serious bug in Ext.data.Store.remove()

[marcing]

I post this error report in behalf of Maciej Hołyszko, who found it and fixed it.

Description:
This bug is causing phantom records to be doubled in some cases (e.g. when using getModifiedRecords()).
Store remove method does not delete a record from modified array.

Solution:

Ext.data.Store.override({
	/**
	 * Remove Records from the Store and fires the {@link #remove} event.
	 * @param {Ext.data.Record/Ext.data.Record[]} record The record object or array of records to remove from the cache.
	 */
	remove : function(record){
		if(Ext.isArray(record)){
			Ext.each(record, function(r){
				this.remove(r);
			}, this);
			return;
		}
		var index = this.data.indexOf(record);
		if(index > -1){
			record.join(null);
			this.data.removeAt(index);
		}
		if(this.pruneModifiedRecords || record.phantom){ /* modified by mh */
			this.modified.remove(record);
		}
		if(this.snapshot){
			this.snapshot.remove(record);
		}
		if(index > -1){
			this.fireEvent('remove', this, record, index);
		}
	}
});

It took us most of the day to locate this bug. I wish ExtJS was helping us to save development time and not constantly slowing it down. We are considering dropping ExtJS, because it is always so buggy and slower with each version contrary to official statements.

I believe that Sencha should offer compensations to bug reporters, who pay for SVN access. We are considering not reporting any more issues, since we are losing money preparing examples and fixing your bugged software. There is nothing you offer in return.

Regards,
Marcin Gil

[cstansbury]

It appears that the Store's save behavior is broken too. If I:

• Add a record (record #1), and then
• Add another record (record #2)

... I will now get 3 records because record #1 is being saved twice! If I were to add a 3rd record, I'd actually wind up with 6 records because record #1 is getting saved (yet a third time), and record #2 is getting saved twice.

This same code has not been modified. The only change is the upgrade to 3.4. It appears that data.XmlStore (or data.Store) is horribly broken in 3.4.

[cstansbury]

Prior to 3.4 I was running w/ 3.1.x. Apparently the behavior for Restful XML services has changed.

• In 3.1, the delete operation could return a "200" + empty response XML. In Ext 3.4 the delete operation was (silently) choking in the XmlReader on a null reference (to the non-existent XML). Therefore you'll need to return at least a single <success/> element.
• In 3.1, the create and update operations could return a "root" element containing a single child that held the ID of the element created or updated. Example: "<comment><id>X</id></comment>". Now, the way that the XmlReader is set up, you'll need to both wrap the "root" element and write the whole object out again (not just the ID). Failure to wrap the root element will prevent Ext from parsing the response at all, and failure to write out the whole object will mean that Ext will interpret the un-echoed fields as being empty.
  Example: "<response><comment><id>X</id>... other elements</comment></response>".

My question is whether or not these behavior changes were throughly documented somewhere that I missed?

[saqwer]

I got next bug. Have created 2 stores ( 1 for combobox and 1 for dataview). So I've added item from store1 to store2, which is already contains item with the same name. And then I tried to remove the last one of two same items. My dataview doesn't removed this item from his rendered list. But meanwhile when I removed one of others same items (items with the same name and which was tested for removing) was hidden together with last one.
Who can suggest how to improve that behavior to right way?