Details
-
Type:
New Feature
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.9 M1 (Ingalls), 1.0.0.APACHE-GEODE-INCUBATING-M2
-
Fix Version/s: 1.7.0.APACHE-GEODE-EA-SNAPSHOT, 1.10 (Unknown)
-
Environment:Spring Data for Pivotal GemFire
-
Reference URL:
-
Sprint:Kay RC1, Kay RC3, Kay GA, Kay SR1, Lovelace M1, Lovelace M2 / M3, Lovelace RC1, Lovelace GA, Lovelace SR1, Moore RC1, Moore RC2, Moore SR1, Moore SR2, Neumann M3, Neumann M4, Neumann RC1, 2020.0.0 - Ockham M1, 2020.0.0 - Ockham RC2, 2021.0.0 - Pascal M1
Description
This JIRA will track the development of SD GemFire's support of the SD Common's PagingAndSortingRepository.
Currently, neither Pivotal GemFire nor Apache Geode implement or support the notion of a database cursor in the querying infrastructure, which allows for such things as [pre-]fetch size, handling concurrent updates and scroll sensitivity.
However, a good interim solution may be to collect a "list" of keys for the values satisfying the query predicate and lazily fetch the values based on the ordered, paged in results.
GemFire/Geode could handle concurrent updates by the user flipping the copy-on-read switch, but scroll sensitivity would not be handled unless the keys were cached. Still, the "cached" keys would be invalidated the moment the user changed the sort order since the "list" is retaining the order the user initially specified, and without the values, there is no way to change the order. Therefore, subsequent queries with the origin predicate could result in a significantly different result set thus changing the number and order of the results.
