After some investigation on my own I noticed that a buffered store uses Ext.util.LruCache which lacks the method filterBy that Ext.util.AbstractMixedCollection has, which seems to be used on a non-buffered store.
Can someone confirm if this is a bug or if I'm doing this the wrong way?

The results of editing a buffered store (the prerequisite to calling sync) are not likely to be desirable. The concept of a buffered store is a large, partially available, result set. Since the entire data set is never available to the client, edits cannot be properly handled. For example, sorting and filtering cannot be updated properly because these must be handled by the server. Also, the page cache has not provision for adding or removing records.

If you turn off the buffered config on the store, what you are doing should work fine.

We are getting the same error when using store.commitchanges() on a buffered store. The only reason though is to get rid of the "dirty" red triangle on the edited cell - the actual data manipulation is handled spearately.

Is there a better (recommended) way to remove the red triangle than commitChanges()?

I disagree with that. Even on a sparse stores there should be some functions to search records in the store or in its page maps. Besides a local filter is common on retrieved records. I have that functionality to narrow down the search on retrieved records.

I also see that the Ext.util.LruChache isn't documented yet, but in that class should be some search functionality.

I think backwardscompatibility is lost now by introducing this new 'buffered' in version 4.2. But hopefully with that bufferedgrid plugin I don't need it anymore.

After some discussion on this last night, it seems that there may be some confusion as to the role of a buffered store and what it represents. In previous versions, many people had to struggle through using a buffered store because what they really needed was buffered rendering. Now in 4.2 these two concerns are separate.

So why use a buffered store? What is its purpose?

A buffered store in 4.2 is *only* useful for managing a dataset on the client that cannot be fully loaded and hence is only partially available. By its nature then, this implies the following are true of buffered stores:

- filtering must be remote
- sorting must be remote
- grouping must be remote
- record lookup is risky
- editing is unsupported

Let me take on the first three first. Imagine a dataset of 10,000,000 records. A buffered store will load only a small part of that dataset (for obvious reasons). If one wants to rearrange or reduce that 10M item set, the only place that can happen correctly is where all 10M items reside - the server. So in 4.2, we will automate setting these to true for a buffered store. Whereas in previous versions you had to do this:

Lookup
Record lookup falls into 2 categories. The most likely use of lookup by record id is because of some action initiated by the user based on records they can see on the screen. Perhaps a row action or similar UI. Obviously, this would be important to support. The "risky" part is any other form of lookup. With a normal (unbuffered) store, a lookup can be performed to see if a record is present *anywhere* in the store.

The problem here is hiding bugs. The only way to verify an app is to test it. It is likely this kind of (ab)use of a buffered store would go undetected since a testing environment may not have enough data and the buffered store may in fact have all records in its cache. So what appears to work in testing could easily fail in production as a result.

Our plan here is to support lookup on a buffered store but if there is no match we will at a minimum issue a diagnostic message or perhaps throw an error back. The reason being that when a record is not in the page cache, that does not mean it is not "in the store" ... not in the 10M item sense. It means we don't know the answer to the membership question. If the record were being displayed somehow, then we would surely find it and all would be well.

Editing
Many things get exciting during edit. If any set operations are in effect (sorting, grouping or filtering) an edit can completely invalidate the cache. Editing the right field could cause the first record to become the last.

Because the page cache has never supported saving/syncing, this was always a hack in previous versions to get working. We will not be enforcing any checks here to prevent you from trying to edit a buffered store's content, but this is not supported.... still.