is there a simple mechanism to ping a transactor from a peer to make sure it's still up? i want to catch :db.error/connection-released The connection has been released errors that sometimes occur when we recreate the database in a non-prod environment

maybe sync?

The latest release includes a transactor health check

You could also use something like sync

oh, awesome

http://docs.datomic.com/transactor.html#sec-1-1

@devth ^^

thanks!

When naming attributes, should cardinality many attributes be plurally named? e.g. for cardinality many, should I use :client/address, or :client/addresses?

Singular I think, you transact [client :client/address address]

I'd check the musicbrainz example for inspiration

musicbrainz uses plural: https://github.com/Datomic/mbrainz-sample/blob/master/schema.edn#L264 so ignore me. Maybe it's just a Datomic version of the old "singular vs plural relations" debate in rdbms

Is it possible/advisable to use with at scale to do optimistic “writes”? Can this be reconciled with reality, when the actual result of the write comes knocking on the door?

@henrik newbie to Datomic here, can’t answer your question. However I am curious: in which cases would you feel the need to do optimistic writes?

@hmaurer It’s entirely hypothetical at this point, but the thought struck me. Some people have expressed fears about write performance, so I thought, what if writes are assumed to have succeeded until proven otherwise?

Or does that lead down into the black pit of eventual consistency?

@henrik it seems to me that if your write-load is so high that Datomic can’t process them quickly enough and you need optimistic writes to maintain decent user-facing performance, you are in trouble. (disclaimer: uninformed opinion)

There might be cases in which you would want optimistic writes (e.g. let a user preview the effects of a change, or testing), but write performance doesn’t seem to be one of them

I am curious as to whether what you suggest is doable though

If you really wanted to I think you could implement it yourself with the log api (http://docs.datomic.com/log.html)

Not sure though…

It might not be entirely necessary, but even so it might be interesting since the vast majority of transactions in a well designed app should succeed in any case. So whatever speed up you get would be gravy, if the effort is small enough.

And then there’s probably the odd transaction where you really want to wait for the round trip, so ideally you should be able to decide per transaction whether to use it or not.

True. Let’s see if someone has an answer to this

@henrik where would you call db.with() ? Peer? Transactor?

@val_waeselynck Peer, right? Call with while simultaneously sending the same thing to the transactor. And once the transactor comes back with a 👍 or 👎, the optimistic aspect of the state would have to be thrown away in lieu of the realistic ditto.

Hi everyone. I can't get my head around whether I should only transact the parts of my entities that have actually been modified or if I can just pass the whole entity and Datomic manages to only persist datoms that were changed

I guess the result of a :find will be the same anyway but if Datomic does not remove unmodified datoms then I am going to clutter my storage…

@henrik I mean, that's do-able, assuming the semantics are okay for your use case.

At that point, though, it's not even eventually consistent. It's, "I won't usually lose your data" consistent.

@gax datomic will diff the transaction and only touch things that it needs to. You can see that easily doing a transaction in repl and then doing it again. The return value will say nothing changed on second run.

Unless you have some kind of scheme to ensure there will be no data loss.

@karol.adamiec ok sweet!

Thanks

I will try that just for the sake of experimenting

I am trying out datomic for some of our use-cases and we have the following query:

[:find [(max ?revision) ?id] 
   :where [_ :appRegistry/revisionNumber ?revision]
                [_ :appRegistry/id ?id]]

two queries, one to find the highest revision, one to retrieve all the apps?

so this cannot be done in 1 go ?

I can't say definitely that it cannot be done

but I will say that often the answer with Datomic is to use multiple queries. Remember that the data is often local inside the peer, so the penalty is not as great at with an SQL db

or we could use a subquery

although I did not find a good example on how that works

then you might as well use d/q twice... you'll find it frustrating to try to express complex queries in a single d/q call, especially involving aggregation

got it

@pesterhazy thanks for the clarification

in the java api, if one wants to do a nested query, how do you refer to datomic.api/q? e.g. this use-case https://groups.google.com/forum/#!searchin/datomic/Kieran/datomic/5849yVrza2M/nHe6QZQ7CGYJ

(d/q '[:find (max ?count)
       :where [(datomic.api/q '[:find ?track (count ?artist)
              :where [?track :track/artists ?artist]] $) [[?track ?count]]]]
  (d/db conn))

right now one app uses Peer.query("datalog string")

hey there, extreme newbie q that I’d appreciate some help on. trying to establish a unique attribute (user’s email) and use it as an ident in a pull query. code roughly looks like the following:

(d/transact conn
            [{:db/ident       :user/email
              :db/valueType   :db.type/string
              :db/unique      :db.unique/identity
              :db/cardinality :db.cardinality/one
              :db/doc         "A user's email address"}])

(d/transact conn
            [{:user/email ""}])

(d/pull (d/db conn)
        '[*]
        {:user/email ""})

figured it out. realized that {:user-email ""} should be a vec, as in [:user-email ""]

@potetm Is it really data loss if it would have been rejected by the db? I guess that's more of a philosophical question than a practical one. Yeah, potentially some kind of "error handling" scheme could be triggered on the delta between the temporary fantasy and the more permanent reality.

@henrik this could be done, but what would be the point? What reads would the with'ed db serve? To me the point of using with ahead of transact is to ensure the transaction wouldn't violate some invariant.

@henrik assuming you're storing the "temporary fantasy" somewhere stable, and that all transactions are reconcilable, there might not be data loss.

Otherwise there absolutely will be. And not in a philosophical sense. If I understand correctly that is.