From ac16b69a68b7b2d6fcd761e2c42c45fda1c8cd79 Mon Sep 17 00:00:00 2001 From: Sven Slootweg Date: Sun, 18 Oct 2020 11:22:06 +0200 Subject: [PATCH] WIP --- ARCHITECTURE.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index de5d7ea..14f1964 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -33,15 +33,15 @@ Some example code using Zap operations might look like the following: // Get a thread with its (visible) posts select("threads", [ - first(), - where({ id: threadID }), - withRelations({ - posts: has("posts.thread", [ - where({ visible: true }), - startAt(offset), - first(10) - ]) - }) + first(), + where({ id: threadID }), + withRelations({ + posts: has("posts.thread", [ + where({ visible: true }), + startAt(offset), + first(10) + ]) + }) ]); ``` @@ -53,8 +53,8 @@ There are two types of operations; regular operations and internal operations: - __Regular operations:__ These are exposed to the end user, and are meant to be used primarily for query-building. They are validated very strictly; they should only allow input that is guaranteed to be representable in the resulting SQL query in some sensible way (unless this cannot be statically ensured). - __Internal operations:__ These are operations that are only meant to be used from optimizers. They are typically validated less strictly, but still do checks on their inputs. There are two main types: - 1. Operations which represent some internal construct that will be used for SQL generation, but that the user will never specify themselves. - 2. Operations which represent a *type* of operations (with subtypes) that *is* available to the user, but that would normally involve multiple different operation methods and where that would be inconvenient for optimizer authors. An example are the `moreThan`, `lessThan`, `equals`, etc. operations which are all represented by a single `condition` internal operation. + 1. Operations which represent some internal construct that will be used for SQL generation, but that the user will never specify themselves. + 2. Operations which represent a *type* of operations (with subtypes) that *is* available to the user, but that would normally involve multiple different operation methods and where that would be inconvenient for optimizer authors. An example are the `moreThan`, `lessThan`, `equals`, etc. operations which are all represented by a single `condition` internal operation. For validating inputs to operations, [Validatem](https://validatem.cryto.net/) is used. Most of the (partial) validation rules live in `src/validators/operations/`, as they are commonly reused across operations. However, the top-level validation rules are defined within the operation functions themselves, and therefore input is validated at AST construction time.