fix: find a definition in whichever schema tree it is authored in - #34
Merged
Merged
Conversation
The renderer looked for authored definitions in the newest schema tree alone, which is right only while there is exactly one. A definition authored at schema 2 stays at schema 2 when schema 3 arrives, and looking only at the top would put it in neither the authored set nor the plain one: it would be rendered nowhere and dropped from the published trees. Every schema tree is searched now, newest first, and a definition belongs to the highest one it appears in. Its own tree keeps its bytes and every tree below renders down from it, as before. Nothing moves today, where one schema tree means the search finds exactly what it found before.
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.
The renderer looked for authored definitions in the newest schema tree alone, which is correct only while there is exactly one of them. Add schema 3 and a definition authored at schema 2, which is where it stays, belongs to neither the authored set nor the plain one: it would be rendered nowhere and dropped from the published trees entirely. Spamassassin, adminer, kafka-ui, pgadmin and redisinsight all sit at schema 2 today, so all five would go.
Every schema tree is searched now, newest first, and a definition belongs to the highest tree it appears in. Its own tree keeps its bytes and every tree below renders down from it, exactly as before.
Nothing moves in the published trees: with one schema tree the search finds what it always found, and the render is byte for byte what main already carries.
The checks gain a three schema case, which fails against the current renderer with "it stays listed in the schema that introduced it" and passes here. The matching fix on the binary side, where the fallback chain jumped from the newest schema straight to the unprefixed path and skipped everything between, is in lerd-env/lerd#1913.