Repository navigation
Accept relations the DD session did not start with - #19
Merged
Merged
Conversation
The DD worker only creates input handles for relations known when it is spawned, and silently drops inserts for any other relation. Two cases hit this: - Engine::add_fact on a brand-new relation lost the fact, so a later query on the DD backend returned nothing while the interpreter returned the row. - A relation that is declared but never derived or populated was not an input, so rules referencing it failed with "relation not found in rels". DdSession now records its input relations and exposes has_input. add_fact pushes a fact for an unknown relation to the EDB and rebuilds the session. build_strata also treats declared relations that no rule derives as inputs. Co-Authored-By: Claude Sonnet 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.
Summary
Make the DD session accept facts for relations it did not start with,
and treat declared-but-empty relations as inputs, instead of silently
dropping facts or failing with "not found in rels".
Problem
The DD worker only creates input handles for relations known at spawn.
Command::Insert/Removedoif let Some(h) = handles.get_mut(&rel),so facts for any other relation vanish. Separately, a relation that is
declared but never derived or populated is not an input at all.
Reproduced on
upstream/mainwith--backend ddagainsttestdata/:The interpreter backend returns
brand_new("x")for the first andNo results.for the second.Fix
DdSessionrecords the relations it has an input handle for(
inputs) and exposeshas_input(&self, rel) -> bool.Engine::add_fact: when a session is live and the relation has noinput handle, push the fact to the EDB and rebuild the session
(via a small private
rebuild_session, which reports errors onstderr) rather than dropping it.
build_strata: relations that areDecl-ed, not derived by any rule,and not already extensional are also session inputs.
After the fix, both cases match the interpreter:
Known limitation
Adding a rule over a relation that was created after the session
started (for example
?- brand_new(X)right after+ brand_new("x").)still fails on DD with "not found in rels". That goes through
add_rule/add_idb, notadd_fact, and is left for a follow-up.Testing
engine::tests::dd_add_fact_new_relation_is_visible:add_facton abrand-new relation is visible via
query_liveandevaluate, andmatches the interpreter. Fails without the
has_input/rebuild change.engine::tests::dd_declared_but_empty_relation_is_queryable: a ruleover a declared-but-empty relation compiles on DD and yields no rows.
Fails without the
build_stratachange (relationlonelynot found in rels).cargo fmt --check,cargo clippy --all-targets --locked -- -D warningsand
cargo test --all-targets --lockedall pass on stable.🤖 Generated with Claude Code