This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-07
Channels
- # adventofcode (38)
- # aleph (1)
- # bangalore-clj (3)
- # beginners (126)
- # boot (165)
- # boulder-clojurians (5)
- # cider (42)
- # cljsrn (11)
- # clojure (203)
- # clojure-greece (6)
- # clojure-hk (1)
- # clojure-italy (11)
- # clojure-new-zealand (1)
- # clojure-nl (1)
- # clojure-russia (112)
- # clojure-spec (86)
- # clojure-uk (176)
- # clojurescript (38)
- # code-reviews (2)
- # core-async (2)
- # cryogen (2)
- # cursive (16)
- # datascript (2)
- # datomic (80)
- # events (2)
- # garden (28)
- # hoplon (115)
- # jobs (1)
- # jobs-discuss (7)
- # klipse (50)
- # lein-figwheel (15)
- # liberator (17)
- # luminus (6)
- # off-topic (8)
- # om (31)
- # onyx (26)
- # parinfer (4)
- # planck (35)
- # protorepl (26)
- # quil (2)
- # re-frame (50)
- # reagent (21)
- # ring (5)
- # rum (2)
- # schema (1)
- # untangled (29)
- # vim (10)
- # yada (40)
how do you connect the peer server to the dev storage? datomic:
fails because ‘foo’ isn’t in the catalog, but leaving off the db name causes it to not match predicate “database-uri?"
@csm you'll need to create the database with a peer first. You can use the bin/repl script included with the Datomic distribution to start a repl with datomic in the classpath
I'm a little surprised about this. For some reason I just assumed idents would be returned as keywords in pull requests. I can see how it's a hassle to convert it every time you want to push those on wire as keywords/strings. I wonder what the use case here. Can't you just use the ident anywhere you could use entity id?
it comes back as a map in pull because you may want to put other metadata on those entities
it is a bit fussy to use full entities for enums, but it’s really not that much extra code to deal with, and the benefits are worth it
210,437 entities in our database are active
all of it is
the only context this code has is the query string
it queries to find the dates and datom count, and the text at the bottom will display the :db/doc
value once i have one
having it as an entity allows you to e.g. mark it deprecated later, with a deprecated boolean schema attr you make for yourself
it boils down to this, for me: enum values have semantic meaning to which we can attach behaviour and metadata
making it a keyword forces you to keep that meaning / metadata outside of your database
Makes sense. Thanks for clearing that up. This idea about metadata on enums would perhaps be useful to have in datomic docs too.
agreed 🙂
@robert-stuttaford thx for enum stuff. one question. How do i write query that returns something constant to clients? i have db on each environment, ids are different. Need to translate them to constants so clients dont have to. Is there any way to do that other than extra query and merge?
and on a related note when should one use keyword then?
for the case where i want to flatten idents into parent maps:
clojure
(defn flatten-idents [m]
(walk/postwalk
(fn [item]
(if (and (map? item) (:db/ident item) (check-its-not-an-attr-here))
(:db/ident item)
item))
m))
other than that, i haven’t really had to deal with it differently
i haven’t ever used :db.type/keyword; in all cases i prefered an ident
i realise this is a personal preference thing 🙂
The d/entity
works differently when using "real" db vs. in-memory db? On real db it returns nil if entity does not exist. with memory db it always returns a datomic.query.EntityMap
. Is this a bug or feature?
(seq (d/datoms db :eavt id-or-lookup-ref))
is my goto, @jarppe
@robert-stuttaford nice bit of clojure. damn i do need to switch away from the REST endpoint 🤓
lol you’re on your own buddy
yeah, good news is that having datomic as db i can spread clojure inside out 🙂
@robert-stuttaford thanks, I'll go with that. Although it would be great to be able to check that entity exists and get the entity in one step.
@mgrbyte d/entity
would be great, but afaik you cant use that to test that entity esists
@jarppe Yeh, it seems that if you use a lookup ref you can (d/entity will return nil if it can't find) - but using a plain long id just gives you a lazy entity
@rauh entid
returns the id associated with a keyword, or if an id
was passed instead of an ident
keyword, it just returns the id
@mgrbyte that explains it, I was so sure that d/entity
returned nil
, but I was using lookup ref at that time. Now I have actual id and must use the d/datoms
as @robert-stuttaford suggested.
@jarppe yep. (-> (d/datoms db :eavt id) first nil?)
would be the way to go in the id case. I'd use this instead of seq
, since you wouldn't want to realise all the datoms for a given id if they did exist (i.e you're just asking if an entity exists for a given id as opposed to all datoms related to that that entity id.
@leov in a query the pull expression takes an ?entity-var like ?e
which can be bound to several entities
several entities in the sense that ?e
will be bound to different values in your resultset
(d/q '[:find (pull ?app [:heroku.app.name :heroku.app.id])
(pull ?config-key [:heroku.app.config.key :heroku.app.config.value :heroku.app.config.app-id])
:where [?app :heroku.app.id ?app-id]
[?config-key :heroku.app.config.app-id ?app-id]] @db/main)
well. I have parent-children relation and trying to get {...parent entity fields... :children [{...} {..}]}
if possible in one query
you might want to look at 'map specifications' from http://docs.datomic.com/pull.html
I suppose its a toss up between re-usability and terseness?
Haven't used datomic enough to know much about the practical benefits of either approach.
Right, ofc
I usually do it if I want something like limit
, which afaik you can't get outside of pull.
You can't use limit expressions with both pull and in pull expressions within a query?
The other way would be using the datoms API i suppose, since this gives you a lazy sequence to iterate over?
Having some issues getting datomic running per the tutorial... I downloaded the zip, brew installed maven, ran bin/maven-install however, still hitting this:
if you want to use the client library you should follow this: http://docs.datomic.com/project-setup.html
Following up on the entity thing a bit belatedly, I can definitely see the utility of having a distinct entity for enums that you can attach stuff to. For our application it didn't seem to outweigh the hassle of needing to do something like @robert-stuttaford's walk/postwalk
code every time we needed to return some code to the client
We generally have clients sending us pull syntax, so it can be a little hard to determine when we would need to execute that kind of post-processing, and doing it every time seemed possibly wasteful (plus wind up driving our client and server code farther apart. potentially)
It seemed easier just to use keywords, which can then be just pulled in like any other attribute value in the pull syntax. If (d/pull)
and friends auto-resolved idents in the output we would probably have gone with them.