Introduce database indices - #1376
Merged
Merged
Conversation
mxsrc
marked this pull request as draft
September 18, 2026 09:36
mxsrc
force-pushed
the
database-indices
branch
4 times, most recently
from
September 21, 2026 14:31
47c9b8e to
366b479
Compare
mxsrc
force-pushed
the
database-indices
branch
from
September 21, 2026 14:54
6312428 to
6ed0d99
Compare
mxsrc
marked this pull request as ready for review
September 21, 2026 15:58
Hamdy-khader
approved these changes
Sep 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Secondary lookups in DBController used to be full-table scans plus an in-memory filter, because entities live under a flat or compound keys and the only access path was a prefix scan. This adds declared secondary indices: a model lists them in
_INDEXES(models/indices.py). Entries live in a disjointindex/<Class>/<name>/<value…>/<entity-id>keyspace and store the entity'sget_id(), so a reader reconstructs the object key without parsing the index key; a Unique index omits the trailing entity id, making the key itself the constraint. Maintenance happens in the same FDB transaction as the entity write (write_to_db / remove / atomic_update), so an index can never describe a record that was never written. Reads go through a singleDBController.query()primitive that range-reads the index and pipelines the point reads. The mechanism has been tested against realistic and targeted workloads in terms of entity size, validating the constant-time lookups.On upgrade, writes immediately write the new indices. The upgrade code backfills the indices for the remaining indices. Optimized reads through indices are gated on the index indicating its readiness, falling back to the current table scans.