Is it possible with pull to pull all attributes only one level deep? Having a tree like data, , which contains many components, using pull, pulls the whole tree (which makes sense). However, I'd like to pull only one level deep. I could use attribute names, but since there may be a lot of them and the pull shouldn't depend on the knowledge of all attributes, I'd rather have a pull of one level deep. This is not recursion I'm after: it's not about friends of friends of friends-relationships. Taking that analogy, it's more a friends of one or more of of friends/mother/father/nephews/nieces/... of, well, that depends on if it's a friend of a friend, or a friend of a mother, or a friend of a father and so on.

Thanks @stuartsierra

@kurt-yagram you could write a query that returned the attributes that you were looking for, i.e.:

‘[:find [?attr1 ?attr2 ?attr3] 
  :in $ ?e 
  :where [?e :entity/attribute ?attr1] [?e :entity/attribute ?attr2] [?e :entity/attribute ?attr3]]

@kurt-yagram what about:

(into {} (d/q '[:find ?an ?v :in $ ?e :where [?e ?a ?v] [?a :db/ident ?an]] db eid))

@bahulneel nice query

remembering that the schema is queryable is something that keeps coming up over and over again for me

very handy

only downside of the above is it returns one ID for ref many fields

but it gets really close

sure

I think you could write a rule to fix that

ah, because of the into

that’s the only reason

ah yes

if you do a merge-with it’ll work

maybe a reduce

@bahulneel yeah, I think something like that may work

@bahulneel you’re right, a reduce is easier

This works

(->> eid
     (d/q '[:find ?an ?v
            :in $ ?e
            :where
            [?e ?a ?v]
            [?a :db/ident ?an]]
          db)
     (reduce (fn [m [k v]]
               (update m k (fn [o]
                             (cond
                               (nil? o) v
                               (sequential? v) (conj o v)
                               :else [o v]))))
             {}))

Although if there's only one in a many you'll only get one

I just switched from dev storage to sql and now I'm trying to figure out how much disk space I should give the transactor(s). The docs only say it's used as temp storage. Does it need much? Does it need to be fast / ssd? Only relevant docs I could find were from the config samples:

# Data directory is used for dev: and free: storage, and
# as a temporary directory for all storages.
# data-dir=data

@ethangracer this would work properly:

(->> eid
     (d/q '[:find ?an ?v ?c
            :in $ ?e
            :where
            [?e ?a ?v]
            [?a :db/ident ?an]
            [?a :db/cardinality ?c]]
          db)
     (reduce (fn [m [k v c]]
               (update m k (fn [o]
                             (if (= :db.cardinality/many c)
                               (if o
                                 (conj o v)
                                 [v])
                               v))))
             {}))

@bahulneel looks right but isn’t quite working for me

anyway it’s a fun idea

definitely doable, just some nuance to figure out

I didn't have a dataset handy to test it on, but the idea is there.

@ethangracer ok so I forgot to get the ident of the cardinality the query part should be:

'[:find ?an ?v ?cn
 :in $ ?e
 :where
 [?e ?a ?v]
 [?a :db/ident ?an]
 [?a :db/cardinality ?c]
 [?c :db/ident ?cn]]

@devth Datomic doesn’t need a lot of space. Faster certainly wouldn’t hurt.

it’s used for local temp/swap

Ok, so e.g. a 10gb local ssd would be enough? Should it be persistent or can it be lost when a transactor fails and gets brought up elsewhere?

more than enough. doesn’t need to be persistent

@marshall awesome, thanks!

awesome, @kurt-yagram the solution above from @bahulneel is far better than mine 🙂

@kurt-yagram @ethangracer altogether here https://gist.github.com/bahulneel/0ac62dda604936b6a22e497bffb33769