is datomic a good fit for managing trees of data (predominently). There are relations between the data at different levels too.

@wistb so DAGs actually :)

I'd sat definitely yes for reading

To be seen for writing

Would be easier if you gave us examples of data, reads and writes

have you seen anyone replacing a hibernate layer with datomic ? Our situation is like that. we use spring/jpa/hibernate/postgress/oracle. In the interest of keeping the business logic in tact, we are wondering if we can replace the ORM with datomic ....

@wistb AFAIK there are no Datomic ORMs (Datomic is not 'R', and its community is not too fond of 'O' 😉 ). Reimplementing all of JPA on top of Datomic would probably be a huge endeavour IMO. Out of curiosity, what leverage do you expect from Datomic if you're planning on 'hiding' it behind a JPA-like interface? Application logic is where the specifics of Datomic usually shine (datalog, rules, pull, entity API, non-remote querying etc.)

Although I do understand the desire to make a smooth transition

facts map to objects better than tables I suppose, so it should definitely be doable

the read interface shouldn't be too hard, I guess you can have each Entity class have a private datomic.Entity field and implement the getters on top of that

writing is probably more problematic

(Datalog beginner) Is there a reason why Datomic/Datomic does not support hash-map return values, e.g. [:find {:id: ?e :title ?title} :where [?e :product/title ?title]] => [{:id 1789... :title "Title 1"} ...] My first guess would be to do with subquerying and set uniqueness

use [:find [(pull ?e [:id :title]) …]

Thanks @karol.adamiec! 🙂

Date/instant attribute naming best practice: :thing/arrival-date vs :thing/arrived-on vs :thing/arrived-at?

I intermittently get:

Exception in thread "main" clojure.lang.ExceptionInfo: Error communicating with HOST 0.0.0.0 or ALT_HOST datomic on PORT 4334

That means peer connected to storage, but could not connect to transactor via the provided "host=" or "alt-host=" config values set in the transactor's transactor.properties file @devth

got it. strange, since i know the transactor is up.

the host=0.0.0.0 sounds just bad

alt-host=datomic relies on "datomic" resolving correctly

(from the peer's perspective)

i think 0.0.0.0 is because i don't know the IP it will get

and datomic does resolve from the peer

(kubernetes dns)

0.0.0.0 is only for peers

so it's not really useful

unless the peer is on the same machien

so i guess it's not used at all

nm, I take that back

it might be used for the bind address

i thought i needed it to be 0.0.0.0 in order to work, but it's been awhile since i first set it up on k8s

might try wrapping it in a retry

don't understand why it intermittently fails

do you know that datomic is resolveable right away?

the name "datomic" I mean

resolveable and routable

it should be but i should verify that

how is storage resolved? also a kubernetes dns name?

kubernetes pods are configured to use an internal dns server

storage (sql) goes through a proxy (google cloud sql proxy) on localhost to the cloud mysql instance

dns is configured automatically on google container engine. not something i touch

so the connection string is always something like datomic:?

right

and the proxy has an IP address, or a name?

datomic:

MYSQL_HOST is always localhost:3306

which is a process running inside the pod using a docker image provided by google

it uses credentials to find and access the cloud sql instance

given a resource name

what I mean is, how does the proxy get the destination address? I am seeing if these are determined via different systems, which would make it possible that one system is up and the other is not yet

yeah two separate systems

e.g. if proxy forwarded to hardcoded IP (likely for google cloud mysql), then maybe dns is just not up yet

i don't know how google's cloud sql proxy works internally

if anything i would suspect kubernetes dns resolution

the proxy has worked flawlessly for other apps

i can ping datomic on startup to see if it resolves to an IP

i wish there was an http endpoint on the transactor i could curl though

yes the proxy is definitely working

that's how the peer got the "datomic" name in the first place

interesting I didn't know about this proxy

https://github.com/GoogleCloudPlatform/cloudsql-proxy

we use ssl auth directly with could mysql

ah

also https://cloud.google.com/sql/docs/mysql/sql-proxy

yeah I looked it up

I suspect it uses the gcloud http apis

but no idea how those resolve

right. might be internal dns inside google network

yeah

magic *.internal names even

@val_waeselynck I liked this : "Application logic is where the specifics of Datomic usually shine (datalog, rules, pull, entity API, non-remote querying etc.)" . It is nice take-away point .

Hi, I have an architecture question. I’ve a Datomic/Clojure based microservice. Some of its transactions are ‘domain events’ that I want to shoot off to kafka. I identify them with an attribute on the relevant transaction entity I’d been playing around with Onyx, it’s cool, but I’m starting think it might be overkill for this use case which is really just grabbing relevant transactions, mapping their attributes to the event structure and sending them on their way to kafka. I’ve been looking at datomic’s TX-report-queue, as it looks like a listener on that guy would pretty much meet my needs. But i’m not clear on some of its semantics. it seems like each peer gets it’s own queue? if so then I’d potentially be processing (num peers) copies of the same transaction/event.

If every entity needs a globally unique identifier, do you guys prefer to add it under an entity namespaced attribute (e.g. for your product entity :product/id or organization entity :organization/id) or globally understood name (e.g. every entity have the attribute`:entity/id`)?

I prefer to have separate ID attributes per "type" of entity, because it allows me to query for them more easily

I don't have to "duck type", I can just look specifically for :product/id 123. Otherwise I'd have to query for :generic-id 123 and then later figure out if facts for that entity is of the type I expect

@augustl Wouldn't your query effectively be the same either way?

'[:find ?name
  :in $ ?id
  :where
  [?e :product/id ?id]
  [?e :product/name ?name]]

'[:find ?name
  :in $ ?id
  :where
  [?e :entity/id ?id]
  [?e :product/name ?name]]

I guess it depends on how you like to structure your queries, yeah

I like to just query for the id and then build entity objects, not pull out attributes in the query

Still seems pretty similar 🙂

(:product/name (d/entity db [:product/id my-id]))
(:product/name (d/entity db [:entity/id my-id]))

with the latter, you wouldn't know what "type" of entity you would get though

so your URL could be /people/5 and that could be an ID of a product, not a person, and you'd still get data from the query

Isn't the type implicit with the entity attributes? i.e. Because the entity has the :product/name attribute it is therefore a Product entity.

It wouldn't make much sense if a Person had a :product/name attribute.

in that case, where you only ask for the product name, that makes sense

but if you want a full collection of attributes you'd just end up with a sloppy system, I'd say

where you would get a person with the id 5 (even though 5 is a product) and all the attributes would be nil

makes more sense to 404 in that case

I think you'd still be covered tho':

(let [{:product/keys [id] :as e} (d/pull db '[*] [:product/id my-id])]
  (if id
    {:status 200 :body e}
    {:status 404}))

(let [{:product/keys [name] :as e} (d/pull db '[*] [:entity/id my-id])]
  (if name
    {:status 200 :body e}
    {:status 404}))

if all your "product" entities has a name attribute, that would work, yeah

And you wouldn't end up with a map of nils. From the docs: > attribute specifications that do not match an entity are omitted from that entity's result map

I guess it's just a matter of taste

checking for a "name" feels like duck typing, and I'd prefer an "actual" type

I think I see what you're getting at: you just want a globally consistent key to check for an entity's type?

yeah

and you can use lookup refs more easily

(d/entity db [:product/id "123"])

How's that different than (d/entity db [:entity/id my-id])?

the built in type check 🙂

no additional check needed to verify that it's actually a product

IIRC, d/entity will always return an entity even if the entity does not exist. So, you'd still need the if.

Yeah, you'd still need to check if pulling :product/id off the entity was nil before proceeding.

(transact conn (into #{[:db/add (d/tempid :db.part/tx) :audit/user x] [:db/add (d/tempid :db.part/tx) :audit/ns y]} other-tx)) resolve both tempid to the same "transact-id". It's a feature? Should I use it??

@souenzzo there can only be one tx tempid id per tx. It's handled specially

@souenzzo you can also use the string "datomic.tx" in recent datomics

"datomic.tx" is a special string that generates :db.part/tx tempid?

you can now use a string as a tempid, normally the tempid is in the :db.part/user partition, except "datomic.tx", which is in the :db.part/tx partition

it is a tempid which always resolves to the currently executing transaction entity

wow cool