Clojurians Log v2

@conrad.p.dean what is the schema for the attribute :country/name ? i could not find the db construction for mbrainz in the datomic repo after a quick skimming

You can find an example schema here I guess: https://github.com/Datomic/mbrainz-sample/blob/master/schema.edn

But I'm not sure where :country/BE comes from.

So, if Datomic allows for any keywords to be :db/id then we can't support this yet.

gotcha -- not yet having support for a keyword-based :db/id makes sense

What's this called in datomic's query language where they have two equivalent ways to grab data, one is inlining a property from the datom datom from the joining entity ( [:country/name "Belgium"] ) where the other can use the entity id for the joining entity ( :country/BE )

;; the following thee queries are equivalent
(d/q '[:find ?artist-name
       :in $ ?country
       :where [?artist :artist/name ?artist-name]
       [?artist :artist/country ?country]]
     db [:country/name "Belgium"])

(d/q '[:find ?artist-name
       :in $ ?country
       :where [?artist :artist/name ?artist-name]
       [?artist :artist/country ?country]]
     db :country/BE)

:country/BE is an "ident", which is short for identifier. [:country/name "Belgium"] is a "lookup ref". in most situations when an entity id (which is just a java.lang.Long) is required/expected, you can use an "ident" or a "lookup ref" instead.

:country/BE comes from a simple fact like [<some entity id> :db/ident :country/BE], which can be created by transacting either: 1. [:db/add "temp id" :db/ident :country/BE] or 2. {:db/ident :country/BE} which is short for 3. {:db/id "temp id" :db/ident :country/BE} which is only needed if you already want to reference this entity from within the same transaction.

lookup refs are mentioned first in the datomic on-prem tutorial: https://docs.datomic.com/on-prem/tutorial.html#pull then in the reference docs here: https://docs.datomic.com/on-prem/identity.html the glossary is also a very helpful page, where you can check how much of datomic do you already understand: https://docs.datomic.com/on-prem/glossary.html

i would also add that these concepts are not specific to "datomic's query language", which btw you can just refer to shorter as "datalog", but it's an inherent convention for referencing entity ids in any context, including transaction data and the various lookup apis, like pull, entity, datoms, etc

the fastest way to gain the most (deep) knowledge about datomic is to watch and practice the "day of datomic" course. https://docs.datomic.com/on-prem/day-of-datomic.html there are 2 recordings of this curriculum 2 years apart. i recommend watching both, though they overlap 80-90%, because it can help you to reinforce your knowledge. you can understand even deeper the beginning of the course in lights of the rest of the material. most ppl can comfortably consume 1 course in about a day, so 2 courses will take 2-3 days. then you shall practice and try to model some of the problem domains u r familiar with. come and ask questions on clojurians, try your small experimental programs on different datomic implementations, like datalog and datahike and datalevin. all together you can learn datomic within a week pretty well, if you can concentrate on it ~6hours a day.

i highly recommend to bite the bullet and just read the entire on-prem documentation too at least once in its entirety. nowadays it's recommended to start with the cloud version as a beginner, but i struggled a lot with that even though i already have quite a lot of experience with the on-prem version.

no, go and study! see you in a week! ;D /me starts his stop watch

i have to add that of course it takes a lot of practice before you can keep all this info in your head, like ~1-3month regular usage, but you will experience a lot less frustration if you batch your learning efforts up-front. it will pay off big time!

thanks! i've been comparing datomic, datalevin, and datahike with each other already this week! I finally have gotten into a position where I'm able to reproduce some things from datomic in the open implementations, but still trying to learn enough about what's missing to figure out if the syntax is just different or if those features are wholly absent. > not specific to "datomic's query language", which btw you can just refer to shorter as "datalog", you're right -- in the context of this channel it makes sense to just call it datalog, but i have some hesitation since i'm so used to the datalog from the 80's, with horn clauses and stuff Datomic's datalog is definitely an extension beyond the original ideas of datalog, so I'm asking specifically about how this part (lookup refs! now i know what to read about, thanks!) works and how to replicate it in datahike (still struggling at the moment) or datalevin (can't even get it to store dates 😬 ). I'm excited that I recently got enough of a footing in datomic's datalog to find gaps in a mozilla project (https://github.com/mozilla/mentat/) where it seems they haven't implemented rule execution, nor recursive rules, so I don't have to keep spinning my wheels on that as a viable embedded datalog db.