in a query you can have a clause like [(get ?e :classification) ?class] and then you can use ?class like any other logic var, join, return etc.

right great that would work - always forget that ?e will be the entity id and not the entire entity, thank you!

That's uncanny timing...I wrote an "idea" note on the project board like 5m before you sent this saying "extend pull syntax to traverse nested data"

I am unsure about the ergonomics of combining pull and get and subqueries as a workaround though. I guess some kind of construct capability would make that kind of thing more plausible, as in https://github.com/Swirrl/matcha#construct

If you have a minimal example in mind I'd be happy to try to help solve it 🙂

Hey @U899JBRPF thanks something like this

(crux/submit-tx node
                  [[:crux.tx/put
                    {:crux.db/id "asw"
                     :cohesic/type :measurement
                     :measurement/display-name "ASW"
                     :measurement/classified-ranges #{{:measurement-name "asw"
                                                       :classification :classification/normal}
                                                      {:measurement-name "asw"
                                                       :classification :classification/mild}}}]])

(crux/submit-tx node [[:crux.tx/put
	                     {:crux.db/id {:measurement-id "asw"
                                       :classification :classification/normal}
                          :cohesic/type :classified-range}]])

(crux/submit-tx node [[:crux.tx/put
	                     {:crux.db/id {:measurement-id "asw"
                                       :classification :classification/mild}
                          :cohesic/type :classified-range}]])

(crux/q
   (crux/db node)
   '{:find [(pull ?measurement [:measurement/display-name
                                {:measurement/classified-ranges
                                 [:crux.db/id
                                  :classification/range]}])]
     :in [?measurement-id]
	 :where [[?measurement :cohesic/type :measurement]
             [(== ?measurement ?measurement-id)]]}
   "asw")

but I don't have a way to go nested into crux.db/id

This is closer

(crux/q
   (crux/db node)
   '{:find [?display-name ?class ?range]
     :keys [display-name classification range]
     :in [?measurement-id]
	 :where [[?measurement :cohesic/type :measurement]
             [(== ?measurement ?measurement-id)]
             [?measurement :measurement/display-name ?display-name]
             [?measurement :measurement/classified-ranges ?class-range]
             [(get ?class-range :classification) ?class]
             [?class-range :classification/range ?range]]}
   "asw")

;;=>
#{{:display-name "ASW", :classification :classification/moderate, :range {:lower 15, :upper 17}}
  {:display-name "ASW",
   :classification :classification/severe,
   :range {:lower 18, :upper 9223372036854775807}}
  {:display-name "ASW",
   :classification :classification/normal,
   :range {:lower -9223372036854775808, :upper 11}}
  {:display-name "ASW", :classification :classification/mild, :range {:lower 12, :upper 14}}}

it makes sense, the moment I abandon the pull join I am actually abandoning the entity I am working against and start going nested

thanks for the example. Could you live with simply repeating the :classification and :measurement AVs as top-level AVs? (as well as keeping them in the ID map)

yeah that's what I have done for now

@U899JBRPF side question, do you have any input around LMDB? Would there be any notable difference with my dataset size?

Sorry, I somehow missed seeing this thread. LMDB is a fine choice, and it will be perceptibly faster for (uncached) reads and slower for writes at pretty much any scale, I think

We have more limited production experience with LMDB, but everything anecdotally suggests it's very low-maintenance