feat: CXL documentation

[patricebender]

TBD

[agoerler]

You can use expressions in various other places

• translated to EDMX-expressions
• to define projections between types
• projections can be resolved at runtime (runtime views)
• expressions can be evaluated in memory

[Akatuoro]

Query does not mean that it is a database query. There can be multiple vehicles for an expression. Conceptually though, it can be understood as part of a query - whether it is either sent to the database, converted to edmx (and then sent to the backend again), or evaluated in memory.
This is an important point though. Expressions are not only meant for database queries.

Keeping this open -> happy for suggestions on how to formulate this.

[renejeglinsky]

There's one example where it's not the text but the box that is clickable. Is that on purpose?

[patricebender]

There's one example where it's not the text but the box that is clickable. Is that on purpose?

actually, I want to have clickable boxes. Will check!

[swaldmann]

Whenever I see Venn diagrams explaining JOINs I'm reminded of this article/rant, where the author makes the case that set theory is a false analogy as JOINs are rather a cross product filtered by a predicate with an optional UNION:
https://blog.jooq.org/say-no-to-venn-diagrams-when-explaining-joins/

Food for thought 🤔 The JOIN diagrams shown there could also come in helpful in some Capire guides.

[Akatuoro]

Thanks for the link! This topic also came up when writing the theory section, because the inner join is indeed $\{ (a, b) \in \text{Authors} \times \text{Books} | a.\text{id} = b.\text{author\_id} \}$ -> a cross product with a filter.

Just jotting down my thoughts:
The key point of the blog entry in regards to why this can not be shown as a Venn diagram is that the sets (Authors and Books) are of a different type and are not union-compatible. So $\text{Authors} \cap \text{Books}$ is indeed not correct.
Rather, we implicitely look at the cross product
$$X = \{ \space (a_1, \dots, a_n, b_1, \dots, b_m) \in \{ \text{Authors} \cup \{(\omega, \dots, \omega)\} \} \times \{ \text{Books} \cup \{(\omega, \dots, \omega)\} \} - \{(\omega, \dots, \omega)\} \space \}$$
with each circle representing:
$$\text{Authors}' = \{ (a_1, \dots, a_n, b_1, \dots, b_m) \in X | a_\text{id} \ne \omega \}$$
$$\text{Books}' = \{ (a_1, \dots, a_n, b_1, \dots, b_m) \in X | b_\text{id} \ne \omega \}$$

Getting the actual authors back is now only an exercise of projection:
$$\{ (a_1, \dots, a_n) \} = \{ \pi_{a_1, \dots, a_n}(\text{Authors}') \} = \text{Authors}$$
-> Select distinct a.* from Authors a full join Books b on 1 = 1

Since the sets are independent of the projection (what we select), any join operations simply filter on the cross product, which imho can be nicely displayed using venn diagrams. So I do disagree with the author of the blog even though they have a point. I also think the join diagrams could come in helpful.

One of the key points in cql / cxl is that path navigation allows us to work on sets and only consider the select list (projection in relational algebra) at the end. When actually writing relational algebra, the tuple needs to be defined explicitely. CQL and SQL also handle null values nicely. When writing relational algebra, null values need to be explicitely included.

[agoerler]

explaining JOINs

But we don't want to explain joins! We have sets of instances of some entity type that are associated with some other instances of in a different set. Sometimes our SQL backends use a JOIN in SQL to compute a cross product of these sets. But this is an implementation detail of the SQL backends.

[agoerler]

please add a hint that you should any path expression used in order by should also be on the select list

[agoerler]

Suggested change

	path expressions can also be used after the `exists` predicate to check for the existence.
	Path expressions can also be used in the `exists` predicate to check wether the set that is referenced by the path is not empty.

[agoerler]

Suggested change

	E.g., to select all authors that have written **at least** one book:
	E.g., to select all authors that have written **at least** one book:

[agoerler]

Suggested change

	Every entity defines a set of all possible instances:
	Every entity defines a set of all instances:

[agoerler]

Suggested change

	A simple select query on Books returns the complete set → all books.
	A simple select from Books returns the complete set → all books.

[agoerler]

Suggested change

	group by genre
	order by genre asc`
	group by genre.name
	order by genre.name`

[agoerler]

No. Using the infix notation to specify the query modifiers makes it really hard to understand (and explain) what the infix does. I think the plain infix filter is easy to understand though.

[agoerler]

this example is easy to understand

[agoerler]

This is related to the query language and not to the expression language, I think. Move to CQL chapter?

[agoerler]

why not Authors.books ?