Arches is a web platform for creating, managing, & visualizing geospatial data. Arches was inspired by the needs of the Cultural Heritage community, particularly the widespread need of organizations to build & manage cultural heritage inventories
GNU Affero General Public License v3.0
212
stars
142
forks
source link
Reduce queries for published graphs when indexing #11513
[x] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
Description of Change
Before, when indexing resources there were 2 queries per graph to get the published graph in the active language. One for the GraphXPublishedGraph row, one for the PublishedGraph row. This was then cached in memory, persisting either for a short period (on the CLI) or potentially forever for server-side operations, which could lead to retrieving stale data.
Now, these are prefetched during optimize_resource_iteration, so that it takes 2 queries total per chunk, no matter how many graphs are involved. A typical chunk size is 500 (2000 // 8), so if two adjacent chunks each contain 500 resources of the same graph, then this might slightly increase queries, because we are no longer perpetually caching, but with a benefit of less memory overhead and better correctness for server-side operations--but in all other cases this should reduce queries by avoiding repetitive published graph queries.
Checklist
I targeted one of these branches:
[x] dev/8
[ ] I added a changelog in arches/releases
[ ] I submitted a PR to arches-docs (if appropriate)
[x] Unit tests pass locally with my changes
[x] I added tests that prove my fix is effective or that my feature works
Types of changes
Description of Change
Before, when indexing resources there were 2 queries per graph to get the published graph in the active language. One for the GraphXPublishedGraph row, one for the PublishedGraph row. This was then cached in memory, persisting either for a short period (on the CLI) or potentially forever for server-side operations, which could lead to retrieving stale data.
Now, these are prefetched during
optimize_resource_iteration, so that it takes 2 queries total per chunk, no matter how many graphs are involved. A typical chunk size is 500 (2000 // 8), so if two adjacent chunks each contain 500 resources of the same graph, then this might slightly increase queries, because we are no longer perpetually caching, but with a benefit of less memory overhead and better correctness for server-side operations--but in all other cases this should reduce queries by avoiding repetitive published graph queries.Checklist
Ticket Background