From 9da5eabbe6eafce5458c3c2826eb30d86ac36680 Mon Sep 17 00:00:00 2001 From: Nick Alexander Date: Wed, 25 Jan 2017 15:08:03 -0800 Subject: [PATCH] Push child Wiki pages into Transacting: namespace. --- Transacting.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Transacting.md b/Transacting.md index 6d96706..690ff72 100644 --- a/Transacting.md +++ b/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.