greg/mentat
1
0
Fork 0
Code Issues 294 Pull requests Packages Projects Releases 9 Wiki Activity

Push child Wiki pages into Transacting: namespace.

Nick Alexander 2017-01-25 15:08:03 -08:00
parent 3814f87154
commit 9da5eabbe6
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
Transacting.md

@ -44,7 +44,7 @@ or it could be used in an _upsert_, like
```
Every lookup-ref must resolve to a unique entid already in the database or the transaction fails immediately. Upserted temp IDs, however, may or may not resolve. If any resolve to _multiple_ entids, the transaction fails immediately. Those that do not resolve will have new entids in the appropriate partition allocated for them.
The upsert resolution process is a multi-step algorithm that iteratively refines sets. See the Wiki notes on [[resolving upserts|Upsert-resolution-algorithm]].
The upsert resolution process is a multi-step algorithm that iteratively refines sets. See the Wiki notes on [[resolving upserts|Transacting:-upsert-resolution-algorithm]].
## SQL evaluation
At this point, the transaction entities are in a streamlined form, like
@ -54,7 +54,7 @@ At this point, the transaction entities are in a streamlined form, like
Using the properties of the relevant attribute, we generate bulk `INSERT` and `DELETE` SQL statements to update the `transactions` and `datoms` tables in the SQL store. The goal is to have SQLite do the work to look up and replace `:db.cardinality/one` datoms, to produce a minimal number of `DELETE` statements, to efficiently `INSERT` fulltext values and the corresponding datoms, etc.
The translation to SQL is not complicated, but there are several fiddly cases. Eventually we'll write Wiki notes on [[translating entities to bulk SQL|Entity-to-SQL-translation]].
The translation to SQL is not complicated, but there are several fiddly cases. Eventually we'll write Wiki notes on [[translating entities to bulk SQL|Transacting:-entity-to-SQL-translation]].
## Transaction report generation
At this point, the `datoms` and `transactions` tables are updated but the transactor itself does not know the details of what has happened! For example, a `:db.cardinality/many` datom may have already existed and _not_ been transacted; or a new `:db/ident` may have been transacted. The transactor therefore queries the `transactions` table to find out what the actual SQL changes have been, for presentation to the `transact` consumer.