Performance: encode tn_order from each node's stable key instead of a dense rank - #233
Draft
stumpylog wants to merge 2 commits into
Draft
Performance: encode tn_order from each node's stable key instead of a dense rank#233stumpylog wants to merge 2 commits into
tn_order from each node's stable key instead of a dense rank#233stumpylog wants to merge 2 commits into
Conversation
…lay-field models - Fix string.letters (Python 2 only) to string.ascii_letters in CategoryWithStringPk - Add TransactionTestCase to ModelWithStringPkTestCase, ModelWithUUIDPkTestCase, and ModelWithoutDisplayFieldTestCase so they are collected by the test runner - Add treenode_display_field to CategoryWithoutDisplayField to enable display-related tests to pass on all four model tiers Override test_get_display and test_get_tree_display in ModelWithoutDisplayFieldTestCase to assert the pk-fallback behavior (get_display_text() returns str(pk)) rather than the name-based display that the other three tiers expect. This enables the test suite to run against all four concrete models (int pk, string pk, UUID pk, no-display-field) instead of just the int-pk tier. The test count increases from 85 to 232.
stumpylog
marked this pull request as draft
August 26, 2026 20:02
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #233 +/- ##
==========================================
+ Coverage 95.07% 95.76% +0.69%
==========================================
Files 11 11
Lines 711 709 -2
==========================================
+ Hits 676 679 +3
+ Misses 35 30 -5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…lobal dense rank tn_order was a global dense-rank integer, reassigned by sorting the entire table on every write. Inserting or reordering one node could force a tn_order rewrite on every row of every tree, not just the one that changed. It's now built from each node's own stable order key (priority + slug + pk, the same key already used to sort nodes for tree traversal), chained with its ancestors'. A node's own segment never depends on its siblings, so adding, removing, or reordering any node, including a new root, never changes another node's tn_order. tn_index/siblings/children still compute exactly as before, so roots-as-siblings semantics are unchanged.
stumpylog
force-pushed
the
fix/tn-order-tree-local-path
branch
from
August 27, 2026 14:46
0b64b57 to
67b1f5f
Compare
stumpylog
changed the title
tn_order to a tree-local materialized pathtn_order from each node's stable key instead of a dense rank
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
1 participant
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.
Describe your changes
tn_orderwas a global dense-rank integer, so any insert/reorder/delete anywhere in the table could rewritetn_orderon every row of every tree.It's now built from each node's own stable order key (priority + slug + pk), chained with its ancestors'. A node's segment never depends on its siblings, so no write anywhere else in the table can change it, including inserting a new root.
Measured on 50 trees x 40 nodes each, real save/signal/
update_tree()path:Trade-offs
get_order()/.orderreturn an opaque sortable string, not a dense-rank integer.Related issue
#45 (specifically this comment suggesting this exact approach), #34 (segments here are fixed-width per-node keys, not free text)
Checklist before requesting a review