Fork me on GitHub

pulling a reference to an ident returns an entity with the ident's db id as well as its db ident:

(d/q '{:find [(pull ?n [:some/ref])]
       :in   [$ ?n]}
     db 999)

=> [{:some/ref [{:db/id 987 :db/ident :some/ident}]}]
whereas pulling a tuple with a reference to an ident only returns its db id
(d/q '{:find [(pull ?n [:some/tuple])]
       :in   [$ ?n]}
     db 999) 

=> [{:some/tuple [987]}]
it would be great if pulling a reference to an ident from a tuple behaved the same way as pulling a reference to an ident from outside a tuple. i could untuple the values in the query constraints and find their idents, but that constrains my results to only entities that have :some/tuple values, unlike pull


in other words, i can't seem to pull from within tuples


Hey! I have recently been looking at Datomic, reading the documentation and watching almost every single video I could possibly find on the internet. I really like what I've seen so far; I do have couple of questions that I still haven't figured out. Any help here would be appreciated. I've seen this idea that once you get a db from a connection — it's an immutable value and you can do queries on it by leveraging the query engine that's embedded in the application. That is a great abstraction, but I am assuming that under the hood the peer library will be grabbing the required datoms from the storage engine; that inevitably will go over the network. With that in mind: • What happens if there's a network failure while fetching the data from the storage? Is the peer library going to retry that automatically? What if it fails continuously? Will I ultimately see a thrown exception out of nowhere? • What happens if to satisfy a query the peer library needs to grab more data from the storage engine? Is that going to block the thread where the query is being executed? (I'm assuming this depends on whether I'm using the sync or async API)


The details of the answers to these questions depend a little bit on whether you're talking about the client API (cloud or on-prem) or the peer API (on-prem only)


Ah ok interesting. I'll definitely take a look at it then


@U05120CBV I've just reviewed the document. I guess my confusion is here > Compared to the Peer API, the Client API introduces a network hop for read operations, increasing latency. Doesn't the Peer API also need to grab the data from the storage engine? How does the data get delivered then?


Peer reads directly from storage itself, client sends the request to peer server or a cloud node, where the storage read occurs


Well ok, so my point still stands @U05120CBV • What happens if there's a network failure while fetching the data from the storage? Is the peer library going to retry that automatically? What if it fails continuously? Will I ultimately see a thrown exception out of nowhere?


Yes it will retry. It may eventually time out and/or throw


Ok understood. So although the db value is immutable, it might fail to deliver the data in edge cases. That clarifies, thanks a lot!

Sam DeSota14:10:05

Hey all, we just had an issue where ##NaN was transacted into a datomic on-prem db, and a couple weird things happened: • It was impossible to update the values, unless you manually used db/retract + db/add, just using db/add would not automatically retract ##NaN value • We also couldn’t search for the ##NaN values with a query Is this known undefined behavior or a bug that should be reported? Seems like ##NaN values shouldn’t even be allowed to be transacted.

👍 3

I am also kind of confused of what client I should be using here :thinking_face:


cloud or on-prem ? or dev-local?


I have a local Datomic instance running on my computer but I could switch to dev-local if that makes the things easier. I'm more curious about why 3 different libraries


if you're using on-prem you can use the peer library or you can use the peer-server & the client-pro library


@U05120CBV Is there a documentation page that explains a little bit the differences and when to use what?


the clients vs peer page i linked in the other thread


Ah all right, I'll check that out before continuing the conversation. Thanks for the help @U05120CBV


Does somebody know how to increase the number of instances in a production topology? Switching the auto scaling group to 3 for example failed when trying to deploy our ion in Datomic Cloud

Joe Lane14:10:11

Have you investigated query groups @U6Y72LQ4A?

Joe Lane14:10:46

You likely DON'T want to be autoscaling your primary group.


I recall someone saying there’s a library out there with a clojure.spec spec for Datomic queries. Does anyone know where I could find it?


Brilliant. Cheers!

Lennart Buit19:10:30

Note, this is the on prem dialect, cloud (and using client to access a peer server on prem), has slight variations

Lennart Buit19:10:23

For example, cloud only allows one shape of :find


Is there any way to check that entity id is temporary? Does (*instance?* datomic.db.DbId val) work?


depends on context. strings and negative numbers can also possibly be tempids


Hm... So, having an entity id, we can not chose the right way to resolve entity, we should add boolean flag is it tempid or not, and then resolve them different ways depending on this flag...

Linus Ericsson09:10:47

In on-prem (maybe also on client) you should use the :tempids key in the transaction result, there and use datomic.api/resolve-tempid to resolve the tempids to realized entity-ids.


@UQY3M3F6D yep, and I do this. But anyway I need a criteria, are some ids temporary, for resolving it that way. Or you suggest to resolve any id as temporary first, and if it is not resolved this way (or throws an exception), then it probably is a real id and trying to use it an non-temporary?

Linus Ericsson15:10:15

if you create your ids with datomic.api/tempid then you can check if they are an instance of datomic.db.DbId. But that requires your code to use the tempid function, of course. If you transact data with tempids, that already can be resolved to entities (through external indexes and more), the tempids can be resolved to already existing entities, yes. Tempids do not have to create new entities, they can be resolved to already existing entities.


What is Datomic's way to achieve this:

[:find ?dbid .
 :in $ ?name ?domain
 (or [?dbid :company/name ?name]
     [?dbid :company/domain ?domain])]


@zilti or-join

👍 3