@ -33,15 +33,15 @@ Some example code using Zap operations might look like the following:
// Get a thread with its (visible) posts
// Get a thread with its (visible) posts
select("threads", [
select("threads", [
first(),
first(),
where({ id: threadID }),
where({ id: threadID }),
withRelations({
withRelations({
posts: has("posts.thread", [
posts: has("posts.thread", [
where({ visible: true }),
where({ visible: true }),
startAt(offset),
startAt(offset),
first(10)
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).
- __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:
- __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.
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.
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.
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.
