Fork me on GitHub
#datomic
<
2017-07-22
>
danielcompton01:07:21

@matan, following up on my post on the mailing list about consistency. At any point, given a database point t that you got from the transactor you can go to your storage to get the actual transactions (ignore the transactor holding them in memory for now). There are two possible outcomes when reading from Cassandra: 1. The data is there, and it is returned 2. The data is not there (perhaps because of eventual consistency and network partitions, perhaps because the node has failed) and an error is thrown It is never possible to get an inconsistent view of the world, just an unavailable one

matan14:07:41

would you not think that from an application point of view, getting an error is not much better than inconsistent state? I mean it is a little less worse, but how would you code your application if for many reads you need to loop on arbitrary retry intervals?

danielcompton04:07:47

They are just different tradeoffs of availability or consistency. Which one you choose depends on your application.

danielcompton04:07:18

> I mean it is a little less worse, but how would you code your application if for many reads you need to loop on arbitrary retry intervals? It depends on your requirements, but returning an error to a client that the service isn't available is always an option

matan14:07:55

@stuarthalloway @hmaurer thanks for the discussion, it sure improved and corrected my understanding. In particular with regard to the natural ability to join across databases (but not atomically transact across different databases?!)

matan14:07:02

Maybe it would have been nice to auto-shard by time, given that most (?) the designated scenarios would not regularly pick in history but rather use one of the latest time points? or maybe joining from same-time shards is typically more straightforward than with other sharding schemes? just asking :face_with_rolling_eyes: