You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We got a strange issue in one of our test suites after upgrading from Datascript 1.0.0 to the latest 1.7.3 release (yeah, I know...). The failure came from a query that was using a not-join clause to test whether an attribute value on an A entity matched an identifier on some other B entity in the database - effectively a referential integrity check. However, the test case that started failing did not include any entities of type B, and the query started returning an empty set after the upgrade.
Based on my reading of the Datomic query reference, this should return the node, since the not-join subquery returns no results as there are no "bar" entities. If there is at least one bar entity, the query works as expected:
This seems like a bug? At least, I don't see anything about order dependence in any docs. The fact that it works correctly on a database that has unrelated entities that satisfy the leading predicate makes me suspect this is related to some empty-relation short circuiting somewhere that's not accounting for this being in a negation clause.
The text was updated successfully, but these errors were encountered:
We got a strange issue in one of our test suites after upgrading from Datascript 1.0.0 to the latest 1.7.3 release (yeah, I know...). The failure came from a query that was using a
not-join
clause to test whether an attribute value on anA
entity matched an identifier on some otherB
entity in the database - effectively a referential integrity check. However, the test case that started failing did not include any entities of typeB
, and the query started returning an empty set after the upgrade.A minimal example showing what this looks like:
Based on my reading of the Datomic query reference, this should return the node, since the
not-join
subquery returns no results as there are no "bar" entities. If there is at least one bar entity, the query works as expected:However, reordering the clauses in the join fixes this on the original example:
This seems like a bug? At least, I don't see anything about order dependence in any docs. The fact that it works correctly on a database that has unrelated entities that satisfy the leading predicate makes me suspect this is related to some empty-relation short circuiting somewhere that's not accounting for this being in a negation clause.
The text was updated successfully, but these errors were encountered: