Open rnewman opened 6 years ago
Consider whether it's better to return TypedValue::Ref(12345) or {:db/id 12345} — the former is an advantage of our type system, and simplifies extraction of values, but the latter might be more regular when considering fetching more values, and is the way Datomic represents an entity in pull.
I personally see Datomic's representation as a facet of their execution model -- referentially transparent and generally lazy. Our execution model is so different that I'd only want the Datomic-like representation for consistency of extract results, as you say.
We could, of course, grow :db/id-ref
or {:db/id}
to disambiguate one case from the other.
To provide an example, Datomic does this:
(pull ?x [:some/long :some/ref])
➡️
{:some/long 12345
:some/ref {:db/id 12345}}
I think we should do this:
{:some/long Binding::Scalar(TypedValue::Long(12345))
:some/ref Binding::Scalar(TypedValue::Ref(12345))}
and if you want the map form, do this:
(pull ?x [:some/long {:some/ref [:db/id]}])
Much of this was done in #694 and #682.
:db/id
, which means we can avoid using rel results in some cases. Rather than[:find [?person (pull ?person [:person/name])] …]
we can do[:find [(pull ?person [:db/id :as :person/id :person/name]) ...] …]
and handle the returned maps.StructuredMap
. This would allow:as :id
instead of:as :something/id
.TypedValue::Ref(12345)
or{:db/id 12345}
— the former is an advantage of our type system, and simplifies extraction of values, but the latter might be more regular when considering fetching more values, and is the way Datomic represents an entity in pull.[ ] Single-step pull execution. A query like
can be executed in a single SQL query. The in-progress implementation will take two.