This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-13
Channels
- # admin-announcements (208)
- # beginners (53)
- # boot (46)
- # cider (10)
- # cljs-dev (26)
- # cljsjs (10)
- # clojure (66)
- # clojure-dev (3)
- # clojure-russia (14)
- # clojurecup (5)
- # clojurescript (302)
- # cursive (22)
- # data-science (1)
- # datomic (10)
- # emacs (1)
- # events (2)
- # hoplon (91)
- # incanter (1)
- # ldnclj (3)
- # leiningen (1)
- # off-topic (2)
- # om (41)
- # re-frame (40)
- # reagent (78)
what is the recommended way of storing something like clj-time/local-date
in datomic? Convert it to a java.util.Date
and then convert it back when reading the attribute? could that be done generically/centrally?
Datomic only knows how to store java.util.Dates, so you’ll have to convert to/from those as appropriate. this is pretty seamless with clj-time.coerce/to-date and /from-date
so you typically convert data from/to your domain manually or do you stick something like prismatic schema coercion in between somewhere? I like it a lot how datomic allows one to store domain data directly without mapping it before and after, and would love to extend that to other types
greetings!
what is the idiomatic(?) way to represent ordered collections in datomic?
items in a collection do not have a "natural" index attribute, and should not know about their order in a collection.
collection, on the other hand – should know the order items are in.
something tells me, that:
- keeping extra entity just for that {:id wrapper-id2 :idx 4 :item item-id1}
,
- and storing collection of such wrappers {:items #{wrapper-id1 wrapper-id2}}
, rather than the actual items {:items #{item-id1 item-id2}}
- might be an overkill.
is it?
I think linked list is common too
@alexmiller: keeping knowledge of the next item in the current one?
@alexmiller: btw, reading "clojure applied" - so smooth, thank you.
ok, I see, linked lists introduce 2 extra levels in between the actual collection and its items. 😕
greetings!
global uuids
say, you have 2 entity types: bus
and route
.
which is more preferable:
1. having both entities sharing :global/id
attribute
{:db/id 2 :global/id uuid2 :bus/model ...}
{:db/id 1 :global/id uuid1 :route/destination ...}
2. or each have global id under entity's namespace:
{:db/id 2 :bus/id uuid2 :bus/model ...}
{:db/id 1 :route/id uuid1 :route/destination ...}
I foresee a tradeoff between "(not)dealing with irregular entity attribute names" and "more(shorter)/less(larger) datalog queries".
Does one of them win in common case?