ArcGIS Pro 2.9.5; Oracle 18c 10.7.1 EGDB; traditional versioning (moving edits to base)
To improve performance, provide an optional setting that would cache the data of a given FC, table, route event layer (dynamic segmentation is notoriously slow), and other layers.
The data would be cached when the layer is added to the map or when the project is opened. When the user refreshes the map (pan, open attribute table, hit refresh in the map or attribute table, etc.) then Pro would query the database to see if any edits have been made since the last cache. If yes, re-query, if no, use the existing cache.
The check for edits would be done by getting the maximum edit date from editor tracking.
select
max(last_edited_date)
from
linear_referencing_standalone_tbl
This idea is specifically for an editor-tracking-based cache mechanism. The thought is that querying the max LAST_EDITED_DATE would be faster than re-querying and redrawing the entire layer, especially if the LAST_EDITED_DATE field has a database index.
I'm aware that there are existing caching mechanisms in Pro. But I've tested via the Diagnostic Monitor > Logs, and Pro doesn't appear to be caching the data using the technique I described. In fact, I couldn't see any evidence of data caching in the Diagnostic Monitor logs.
Notes:
Some relevant questions from Esri Case #03632162 - New workspace caching in Pro 3.3 — Improved GP performance in EGDBs?:
Me:
What triggers Pro to re-query the data (clear the cache)?
For example, does it only re-query if the underlying data has been edited? How does Pro know when a table in an Oracle 18c 10.7.1 EGDB has been edited, especially if editor tracking isn’t enabled? It is my understanding that there isn’t a clean way to know when a row was last updated using OOTB Oracle database functionality.
Reminder: Route event layers utilize both an M-enabled FC and a separate standalone table (linear referencing table). So I would think Workspace Caching would need to cache and re-query both of those FCs/tables, and have a way to know when they were last edited.
Also, a schema change to a FC or table would also require a re-query to be triggered too.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.