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

Typos.

Richard Newman 2017-01-25 15:09:48 -08:00
parent f4bc3269ad
commit e756cd1ea7
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
Transacting.md

@ -30,7 +30,7 @@ This is the point in the process at which the contents of the database — in pa
The entities of the parsed transaction are walked to map keyword idents to numeric entids using the ident mappings. Syntactic sugar like the map notation and the embedded vector notation are expanded into multiple entities. Attribute/value pairs are checked to ensure that they are well-typed.
## SQL transaction opened
This is the point in the process at which the contents of the SQL store are used. Therefore, we open a SQL write transaction to isolate our multi-step process from concurrent readers. (We assume that writes are serialized. See the Wiki notes on [[modeling the DB and connection in Rust|Thoughts:-modeling-db-conn-in-Rust]].
This is the point in the process at which the contents of the SQL store are used. Therefore, we open a SQL write transaction to isolate our multi-step process from concurrent readers. (We assume that writes are serialized. See the Wiki notes on [[modeling the DB and connection in Rust|Thoughts:-modeling-db-conn-in-Rust]].)
## Resolution
Next, the set of attribute/value pairs requiring resolution is collected. There are two ways that an attribute/value pair can require resolution: it can be used in a _lookup ref_, like
@ -42,7 +42,7 @@ or it could be used in an _upsert_, like
[[:db/add "tempid" :user/unique-attribute EXISTING-VALUE]
[:db/add "tempid" :user/other-attribute NEW-VALUE]]
```
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.
Every lookup-ref must resolve to a unique entid already in the database; if not, 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|Transacting:-upsert-resolution-algorithm]].
@ -57,7 +57,7 @@ Using the properties of the relevant attribute, we generate bulk `INSERT` and `D
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.
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 in the transaction report.
## Schema evolution and transaction finalization
Using the report generated in the previous step, the transactor interprets any `:db.install/*`, `:db.alter/*`, and changes to the schema definitions encountered.