Conversation
…entity Backend now owns SDS frame decoding, delta reconstruction, sketch readouts and native batch frames, and the stored-definition semantic fragment. The logical dataset is recorded on the materialization and in `SummarySemantics::Planner`, so equal fragments over different datasets get different definition IDs. Planner stays deployment-agnostic. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Companion to the ASAPPlanner #462 split (ProjectASAP/ASAPPlanner#472–#475). Based on
main; the Planner pin (4b0839c) is unchanged.Before this PR
Backend used two things that are deployment concerns but lived in ASAPPlanner:
asap_physical_operators::stored_state: sketch frame decoding (modified-OTLP proto and msgpack), delta reconstruction, sketch readouts and native batch frames.planner_types::post_asap::SummarySemanticFragmentv2, which embeddedLogicalDatasetIdentityinside the Planner fragment.After this PR
Backend owns both. The new Planner layers drop them.
sketch_db/query/{decoders,delta_apply,sketch_readout}.rsandsketch_db/data/native_batch.rshold the SDS code, which used to be re-export shims.asap_types::semantic_fragmentholds the v1SemanticFragment(a structural dependency closure) andLogicalDatasetIdentity.PrecomputeMaterialization.dataset_identity;SummarySemantics::Planner { dataset, fragment }.KLL(latency)and tenant B'sKLL(latency)still get differentSummaryDefinitionIds. The check againstingest.dataset_identitynow compares the materialization's dataset.Not in this PR
stored_state::readout::exact_readout[_optional]) are Planner semantics and are still called from the Planner at this pin.CompiledPhysicalDag::encode/decode) moves when Backend bumps its Planner pin.Validation
cargo test --workspace: 1556 passed.cargo clippy --all-targets -D warningsandfmt --check: clean.dataset_identity_is_part_of_definition_id;dataset_identity_survives_binding_and_rejects_wrong_input, which now also rejects a forged materialization dataset.semantic_fragmentandnative_batchunit tests still run.control_plane/build.rsneeds Go onPATH, as before.🤖 Generated with Claude Code