Fork me on GitHub

@thedavidmeister: it’s just a half of JS unboxed int range


first half for entids, second for tx ids


@fasiha: yes, I’d recommend starting with basic datomic concepts first, because there’s little to none DS tutorials


@fasiha: I am working on a series as I learn, not exhaustive or complete yet, but pragmatic.


@tonsky: thanks for weighing in (and thanks for datascript 😄). Because I'm a big baby and didn't want to set up datomic and figure out these schemas etc., I've managed to cobble together enough of a mental picture via your articles, @verma's posts, and to become comfortable referencing the Datomic docs.


If I can ask a question about data layout. Suppose I'm writing a crowdsourced translation site like, which has several phrases in various languages, and people can add translations for them, and vote for which translations are the best. I'm envisioning storing something like this in datascript:

{:original/text "Bonjour"
 :original/language :fr
 :original/translations [{:translation/text "Hello"
                         :translation/language :en
                         :translation/author {:user/username "user1"
                                              :user/email ""}
                         :translation/upvotes [{:user/username "user10"
                                                :user/email ""}
                                               {:user/username "user11"
                                                :user/email ""}
                                               ; ... other users
                         ; another translation
My question is, does it make sense to use a schema with :original/translations, :translation/author, and :translation/upvotes as refs? And with :original/translations & :translation/upvotes having cardinality many, while :translation/author having cardinality of only one?


I'm trying to get a handle on when I should use refs versus just a list, and if three levels of nested refs is too much (i.e., will lead to overly complicated queries)


I would keep the data pretty flat and use refs to refer around stuff, this could become a nightmare when querying stuff


as far as I know though simple_smile


behind the scenes they will all be converted into datums


so I guess its upto you, but how you model your data and your mental picture of it is important, I have come to admire the flat structure of things and refs to link things together, but I am just starting to learn things .. so ...


@verma, thanks! I think I see what you mean. Let me try to make some changes and report back simple_smile