3 ms·

I don't know whether it was intentional or not, but IIRC DataScript opted for sequential intra-transaction semantics instead.

by refset 2y ago

huahaiy 2y ago
Correct. I don't know about DataScript's intention, but it is intentional for Datalevin, as we have tests for sequential intra-transaction semantics.
- tonsky 2y ago
  The idea was that it allows you to add something first and then build on top of it, all in the same transaction
stuarthalloway 2y ago
It is worth noting here that Datomic's intra-transaction semantics are not a decision made in isolation, they emerge naturally from the information model. Everything in a Datomic transaction happens atomically at a single point in time. Datomic transactions are totally ordered, and this ordering is visible via the time t shared by every datom in the transaction. These properties vastly simplify reasoning about time. With this information model intermediate database states are inexpressible. Intermediate states cannot all have the same t, because they did not happen at the same time. And they cannot have different ts, as they are part the same transaction.
- refset 2y ago
  Thank you for the explanations. Do you happen to know why transactions ("transaction requests") are represented as lists and not sets?
  - stuarthalloway 2y ago
    When we designed Datomic (circa 2010), we were concerned that many languages had better support for lists than for sets, in particular list literals and no set literals. Clojure of course had set literals from the beginning...
  - richhickey 2y ago
    An advantage of using lists is that tx data tends to be built up serially in code. Having to look at your tx data in a different (set) order would make proofreading alongside the code more difficult.
aaroniba 2y ago
Yes. Perhaps this is a performance choice for DataScript since DataScript does not keep a complete transaction history the way Datomic does? I would guess this helps DataScript process transactions faster. There is a github issue about it here: https://github.com/tonsky/datascript/issues/366 https://github.com/tonsky/datascript/issues/366

I don't know whether it was intentional or not, but IIRC DataScript opted for sequential intra-transaction semantics instead.

by refset 2y ago

I don't know whether it was intentional or not, but IIRC DataScript opted for sequential intra-transaction semantics instead.

huahaiy 2y ago

Correct. I don't know about DataScript's intention, but it is intentional for Datalevin, as we have tests for sequential intra-transaction semantics.

tonsky 2y ago
The idea was that it allows you to add something first and then build on top of it, all in the same transaction

stuarthalloway 2y ago

It is worth noting here that Datomic's intra-transaction semantics are not a decision made in isolation, they emerge naturally from the information model. Everything in a Datomic transaction happens atomically at a single point in time. Datomic transactions are totally ordered, and this ordering is visible via the time t shared by every datom in the transaction. These properties vastly simplify reasoning about time. With this information model intermediate database states are inexpressible. Intermediate states cannot all have the same t, because they did not happen at the same time. And they cannot have different ts, as they are part the same transaction.

refset 2y ago
Thank you for the explanations. Do you happen to know why transactions ("transaction requests") are represented as lists and not sets?
- stuarthalloway 2y ago
  When we designed Datomic (circa 2010), we were concerned that many languages had better support for lists than for sets, in particular list literals and no set literals. Clojure of course had set literals from the beginning...
- richhickey 2y ago
  An advantage of using lists is that tx data tends to be built up serially in code. Having to look at your tx data in a different (set) order would make proofreading alongside the code more difficult.

aaroniba 2y ago

Yes. Perhaps this is a performance choice for DataScript since DataScript does not keep a complete transaction history the way Datomic does? I would guess this helps DataScript process transactions faster. There is a github issue about it here: https://github.com/tonsky/datascript/issues/366 https://github.com/tonsky/datascript/issues/366