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:
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.
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.