Fork me on GitHub
Lone Ranger00:05:55

anyone have any tips for documenting schema or perhaps querying schema? like if I bring on a new dev how are they going to know what schema are available short of digging through where they were initially transacted?

Lone Ranger00:05:42

also does anyone happen to know if bin/console runs as a client or peer?


@goomba console is a peer

Lone Ranger01:05:08

gotcha, thank you


hey everyone. just curious about any way of building queries programattically. anyone tried this?

Lone Ranger01:05:08

that's a good question, also something I'm looking into

Lone Ranger01:05:03

right now I'm wrestling with just building them 😂


haha yea. just coming to notice that i have a few queries, with only slight changes. been messing with syntax-quotes all day trying to find a nice way to go about it.


@gavanitrate - check out the query reference documentation starting here:


(Or maybe a bit before.)


The idea is that your query can be parameterized with "inputs".

Lone Ranger01:05:28

Okay I finally understand now that this needs to be executed on the peer and will not work on the client

Lone Ranger01:05:56

@jeff.terrell I'm not sure if @gavanitrate is trying to do something similar to what I'm trying to do or not but if you want to view the database as a state-space, for, say, an AI agent to navigate through, could potentially require more direct syntactic manipulation of the queries than just manipulating the inputs

Lone Ranger01:05:17

then again, maybe not

Lone Ranger01:05:43

but part of the appeal of clojure in general (for me (for AI)) is the interesting concept of programmatic code construction

Lone Ranger01:05:56

and this is a perfect example


I mean, you could certainly go crazy with macros that wrap the query interface, but I think the usefulness of that over just simple functional inputs to the query is…not that high.

Lone Ranger01:05:59

you could be 100% correct


There's also the pull API, in case that is better for what you're trying to do.

Lone Ranger01:05:38

step 1 is I need to figure out what I'm trying to do 😂

Lone Ranger02:05:24

I don't know about anyone else but I absolutely programmatically create schema

Lone Ranger02:05:48

one of my favorite things about datomic is giving you the ability to do that

Lone Ranger02:05:02

since it's so chock full of data driven goodness


i'm mostly just trying to allow toggling of certain where clauses. e.g.

(defn commercial-properties
    [cnx {:keys [postcode]}]
      '[:find ?p .
        :in $ ?postcode
        [?p :property/type :commercial]
        (when ?postcode [?p :property/postcode ?postcode])]
      (d/db cnx) postcode))
ideally, if the postcode is not provided, all commercial properties will be returned. this is probably not idiomatic at all though 😆

Lone Ranger02:05:33

oh, neat. Does that work? 😮

Lone Ranger02:05:11

also, is it possible to retract schema? Or do you just rename them?


nah, that's just pseudocode.


think schema retraction is not possible. as your history still requires it. excision might be worth looking into though.


Of course, you could have separate functions, commercial-properties and commercial-properties-for-postcode. But I see what you mean. That's a good use case for your question.


I'd try asking again in the morning if you don't get an answer by then @gavanitrate. I'm interested in hearing the answer too.

Lone Ranger02:05:35

@gavanitrate yeah you're probably right unfortunately I polluted one of my namespaces with a schema name I didn't intend 😛

Lone Ranger02:05:53

yeah it looks like even excising doesn't work to get rid of a schema... I think my solution will be just to create a namespace called :dead that I move typos to 😛


@goomba why does my query only work on a peer?

Lone Ranger03:05:51

@favila it seems like the predicates are really restricted on a client


Huh. Does clojure.core/namespace work?

Lone Ranger03:05:56

{:cognitect.anomalies/category :cognitect.anomalies/incorrect,
 "The following forms do not name predicates or fns: (namespace)",
   :t 1207,
   :next-t 1208,
   :history false}]}

Lone Ranger03:05:00

is a result of

Lone Ranger03:05:19

(pp/pprint (<!! (client/q conn {:query '[:find [?attr-ident ...]
                                         [?attr :db/ident ?attr-ident]
                                         [(namespace ?attr-ident) ?attr-ns]
                                         [(= ?attr-ns "user")]
                                :args  [(client/db conn)]})))

Lone Ranger03:05:48

but it works just fine with

Lone Ranger03:05:17

(d/q '[:find [?attr-ident ...]
       [?attr :db/ident ?attr-ident]
       [(namespace ?attr-ident) ?attr-ns]
       [(= ?attr-ns "user")]

Lone Ranger03:05:00

magic! ¯\(ツ)

Lone Ranger03:05:42

clojure.core/namespace is also a no go @favila

Lone Ranger03:05:07

{:cognitect.anomalies/category :cognitect.anomalies/incorrect,
 "The following forms do not name predicates or fns: (clojure.core/namespace)",
   :t 1207,
   :next-t 1208,
   :history false}]}


Does excision also clear transaction and associated metadata?


hey all! I was noticing that pull syntax in queries (e.g. [:find [(pull $src-var ?foo [*]) ...]]) works for queries with multiple data sources. note $src-var. without $src-var, the pull syntax appears to pick the "first" data source in :in. I can't find a reference to the above src-var syntax in the documentation - is this simply undocumented, did I miss it somewhere, or am I getting into "this is undefined, and we may remove this in the future without warning" territory?

Lone Ranger20:05:53

I don't know if it's the same as for query but in the "day of Datomic Training" they mention that the $ source var is implicit unless specified to allow you to join over multiple dbs


I'm joining over multiple DBs in my query (the :where clause), but when pulling the attributes of an entity, I need to specify which database those attributes come out of. I've managed to figure out how to do that (above), but I don't see where it's documented (check the definition of pull-expr)


@gws this is undocumented, I discovered it by accident (actually I didn't know it was optional for a while, was doing by analogy of d/pull) and I don't know if there's a reason it's undocumented (other that simple oversight) or if it's safe to depend on it in the future


@gws I was hoping a Cognitect would chime in during the day and answer that


I sort of suspected it was undocumented, but before I move this query out to production I'd like to know more. thank you!


I have been using this for a while and I can't conceive of a reason it would be unsafe


verify that two pulls of the same eid from different dbs yield different results, and keep that as a regression test somewhere


so [:find (pull $a ?e [:db/doc]) (pull $b ?e [:db/doc] :in $a $b :where [(ground 1001) ?e]], after transacting {:db/id 1001 :db/doc "a"} and {:db/id 1001 :db/doc "b"} in two fresh dbs


excellent, thank you for the head start too

Lone Ranger21:05:36

does anyone know of good tools for importing SQL data? I'm toying around with writing some automatic schema generation stuff but if there's some stuff out there already would rather leverage that


Say, if I have an attribute that is :db.type/ref and :db.cardinality/many, does it act more like a set or a bag? Eg, will it hold more than one reference to the same entity?


@timgilbert everything in datomic is set semantics


the indexes themselves are ordered sets


(the datom indexes)


Ok. So then if I had :db.type/string, I wouldn't be able to store ["a" "a"] as the value, I take it


Ok, cool. Thanks for the second time today @favila! 🍻


The only exception is that you can get a 'bag' using the :with grouping


For aggregations