Fork me on GitHub
#datomic
<
2015-12-13
>
gerrit13:12:34

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?

robert-stuttaford15:12:14

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

gerrit16:12:30

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

misha21:12:42

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?

Alex Miller (Clojure team)21:12:10

I think linked list is common too

misha22:12:42

@alexmiller: keeping knowledge of the next item in the current one?

misha22:12:46

@alexmiller: btw, reading "clojure applied" - so smooth, thank you.

misha22:12:42

ok, I see, linked lists introduce 2 extra levels in between the actual collection and its items. 😕

misha22:12:31

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?