This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-25
Channels
- # aws (2)
- # beginners (57)
- # boot (31)
- # carry (15)
- # cider (9)
- # cljs-dev (9)
- # cljs-experience (32)
- # cljsrn (94)
- # clojure (129)
- # clojure-dusseldorf (3)
- # clojure-greece (4)
- # clojure-italy (8)
- # clojure-norway (3)
- # clojure-russia (344)
- # clojure-sg (39)
- # clojure-spec (2)
- # clojure-uk (39)
- # clojurescript (84)
- # core-async (99)
- # cursive (10)
- # data-science (1)
- # datascript (4)
- # datomic (66)
- # emacs (10)
- # graphql (4)
- # hoplon (28)
- # jobs (15)
- # luminus (3)
- # lumo (5)
- # off-topic (23)
- # om (4)
- # onyx (32)
- # pedestal (24)
- # re-frame (2)
- # reagent (7)
- # ring-swagger (32)
- # spacemacs (4)
- # untangled (57)
- # utah-clojurians (1)
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?
also does anyone happen to know if bin/console
runs as a client or peer?
gotcha, thank you
hey everyone. just curious about any way of building queries programattically. anyone tried this?
that's a good question, also something I'm looking into
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: http://docs.datomic.com/query.html#sec-5-6
(Or maybe a bit before.)
The idea is that your query can be parameterized with "inputs".
Okay I finally understand now that this needs to be executed on the peer and will not work on the client
@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
then again, maybe not
but part of the appeal of clojure in general (for me (for AI)) is the interesting concept of programmatic code construction
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.
you could be 100% correct
There's also the pull API, in case that is better for what you're trying to do.
step 1 is I need to figure out what I'm trying to do 😂
I don't know about anyone else but I absolutely programmatically create schema
one of my favorite things about datomic is giving you the ability to do that
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]}]
(d/q
'[:find ?p .
:in $ ?postcode
:where
[?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 😆oh, neat. Does that work? 😮
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.
@gavanitrate yeah you're probably right unfortunately I polluted one of my namespaces with a schema name I didn't intend 😛
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 😛
@favila it seems like the predicates are really restricted on a client
{:cognitect.anomalies/category :cognitect.anomalies/incorrect,
:cognitect.anomalies/message
"The following forms do not name predicates or fns: (namespace)",
:dbs
[{:database-id
"datomic:",
:t 1207,
:next-t 1208,
:history false}]}
is a result of
(pp/pprint (<!! (client/q conn {:query '[:find [?attr-ident ...]
:where
[?attr :db/ident ?attr-ident]
[(namespace ?attr-ident) ?attr-ns]
[(= ?attr-ns "user")]
]
:args [(client/db conn)]})))
but it works just fine with
(d/q '[:find [?attr-ident ...]
:where
[?attr :db/ident ?attr-ident]
[(namespace ?attr-ident) ?attr-ns]
[(= ?attr-ns "user")]
]
db)
magic! ¯\(ツ)/¯
clojure.core/namespace
is also a no go @favila
{:cognitect.anomalies/category :cognitect.anomalies/incorrect,
:cognitect.anomalies/message
"The following forms do not name predicates or fns: (clojure.core/namespace)",
:dbs
[{:database-id
"datomic:",
:t 1207,
:next-t 1208,
:history false}]}
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?
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 pull
ing 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
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
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
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! 🍻