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
Datomic expects to bind a 4th element to a transaction "t" value.
e.g. [:entity :attr ?value ?t]
To do this, the basic graph patterns will need to result in a t-value lookup in the indexes. These are currently stored in the durable system in another index (and will require a join), and not stored at all in the in-memory index (ticket #198).
The current graph API has resolve-triple with 4 arguments (graph, subject, predicate, object).
We should consider new arities here, though a simple extension to a 5th argument will cause problems with considering bindings of statement IDs. The new arity may need to accept 6 arguments.
When considering the new arities with respect to #200 we are looking for the following mappings of BGPs:
User Syntax
Internal Representation
[?e ?a ?v]
[?e ?a ?v _ _]
[?e ?a ?v ?t]
[?e ?a ?v _ ?t]
[?e ?a ?v :as ?stmt]
[?e ?a ?v ?stmt _]
[?e ?a ?v ?t :as ?stmt]
[?e ?a ?v ?stmt ?t]
There are 3 cases to consider:
The t value is variable: Lookup the value and return in bindings.
The t is set, along with other values: The t value is then used as a filter (directly on statements for in-memory, and via the tSPO index for durable).
The t is set, and everything else is variable: Filter for in-memory, but use the tSPO index for durable storage.
in memory: Iterate over every triple in SPO. Filter by transaction value
durable: Binary search the tspo index on column 0 for the t value, and t+1.
This gives 2 longs: lower-bound, upper-bound.
Result is: (map (fn [id] (subvec (get-record tspo id) 1)) (range lower-bound upper-bound))
Datomic expects to bind a 4th element to a transaction "t" value.
e.g.
[:entity :attr ?value ?t]
To do this, the basic graph patterns will need to result in a t-value lookup in the indexes. These are currently stored in the durable system in another index (and will require a join), and not stored at all in the in-memory index (ticket #198).
The current graph API has
resolve-triple
with 4 arguments (graph, subject, predicate, object).We should consider new arities here, though a simple extension to a 5th argument will cause problems with considering bindings of statement IDs. The new arity may need to accept 6 arguments.
When considering the new arities with respect to #200 we are looking for the following mappings of BGPs:
[?e ?a ?v]
[?e ?a ?v _ _]
[?e ?a ?v ?t]
[?e ?a ?v _ ?t]
[?e ?a ?v :as ?stmt]
[?e ?a ?v ?stmt _]
[?e ?a ?v ?t :as ?stmt]
[?e ?a ?v ?stmt ?t]
There are 3 cases to consider:
t
value is variable: Lookup the value and return in bindings.t
is set, along with other values: Thet
value is then used as a filter (directly on statements for in-memory, and via the tSPO index for durable).t
is set, and everything else is variable: Filter for in-memory, but use the tSPO index for durable storage.Depends on
t
values from #198The text was updated successfully, but these errors were encountered: