Clojurians Log v2
datomic
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}]}](d/q '{:find [(pull ?n [:some/tuple])]
:in [$ ?n]}
db 999)
=> [{:some/tuple [987]}]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 pullin other words, i can't seem to pull https://docs.datomic.com/cloud/schema/schema-modeling.html#enums 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)
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.
I am also kind of confused of what client I should be using here :thinking_face:
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
Have you investigated query groups @pvillegas12?
You likely DON'T want to be autoscaling your primary group.
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)
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?
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
Ah ok interesting. I'll definitely take a look at it then
if you're using on-prem you can use the peer library or you can use the peer-server & the client-pro library
@marshall 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 @marshall
This library defines a bunch of datomic specs https://github.com/alexanderkiel/datomic-spec/blob/master/src/datomic_spec/core.clj
Brilliant. Cheers!
Note, this is the on prem dialect, cloud (and using client to access a peer server on prem), has slight variations
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?
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.
@oscarlinusericsson 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?
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
:where
(or [?dbid :company/name ?name]
[?dbid :company/domain ?domain])]
@zilti or-join
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...
@marshall 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