Repository navigation
refactor: hold planner contexts natively and call native helpers directly - #1121
Merged
Merged
Conversation
…ontexts in Rust PlannerScopeResolution, PlannerIdentityContext, PlannerRelationsContext, ModelPlanContext and PlanEntryBuildInputs are frozen native classes with typed fields instead of generic native records. Plan entry construction, SQL resolution and cursor bound computation read their fields directly. Constructors take the same keywords; the classes no longer support dataclasses.replace.
Model migration requests, declarations, discovery results and compatibility results are Rust structs. Discovery, fingerprint matching, origin resolution, compatibility checks, decisions, execution choices, redirected cursor inspection and the live-state inspection are called directly instead of through the native module. Removes the corresponding native records and pyfunctions, none of which had a Python caller.
Planner resolution, entry, migration, scenario, warehouse, audit and command-plan code calls the native helpers it needs as Rust functions instead of looking them up on the native module and calling them with keyword dictionaries. Keyword-only helpers receive their arguments directly; signature helpers receive typed values. SQL code scanning in reference resolution uses the scanner directly, and the migration fingerprint cache default is constructed natively. Calls that tests deliberately replace on the native module stay module lookups: SQL test planning, migration fingerprint computation, table type planning, and the compile pipeline's execution plan and Python run outputs. The stale-identity unit test now supplies the project fields change detection reads instead of replacing it.
…r, check and diff The freshness, janitor, check, diff and deferred-target code calls the native discovery, graph, selection, connection, target, progress, state and output helpers it uses as Rust functions instead of looking them up on the native module. SQL test chain resolution is called directly; SQL test planning stays a module lookup because tests observe it there. Native classes the commands construct (progress reporters, the event writer, the cost context and freshness errors) are still created through the module.
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.
Why
The planner and the freshness, janitor, check and diff commands still held their contexts as generic Python records and reached native helpers through module lookups and keyword dictionaries.
Changes
Verification