Differences

This shows you the differences between two versions of the page.

--- tutorials:basic-to-advanced-xl-queries [2024/12/04 19:34] – tim2
+++ tutorials:basic-to-advanced-xl-queries [2025/01/10 11:14] (current) – gaetan
@@ Line 2: / Line 2: @@
-===== Path queries =====
+This tutorial is more of a quiz than a tutorial, for the different type of queries a graph and a set of quests are provided.
+For each quest, the answer and an explanation is provided. Yet it is important to mention that there can be several solutions, for most of this problems.
+===== Relational queries =====
 <code java>
@@ Line 17: / Line 21: @@
 </code>
-{{ :tutorials:graph_quest_path.png?800 |}}
+|{{ :tutorials:graph_quest_path.png?800 |}}|
+| The graph created by the code above |
@@ Line 25: / Line 29: @@
 <hidden answer>
 __In a Context:__
 ''%%(*Node*)%%''
 __In a Query:__
 ''%% Node ==> %%''
+__Why:__
 The query system in XL works based on the concept of object orientation from java, therefore a Query also selects all Objects, that extend the class used in the pattern. And since all Nodes in the graph extends the class Node...
@@ Line 72: / Line 78: @@
 Model.B[id=39]
 </code>
+__Why:__
 The ''>'' arrow describes a successor connection and since Node addresses all Objects in the graph this query addresses all B's that are linked by an successor. For the Query, the use of the context syntax (''%%(*...*)%%'' is necessary to clarify that this part of the pattern is not suppose to be replaced.
@@ Line 97: / Line 106: @@
 Model.B[id=36]
 </code>
+__Why:__
@@ Line 122: / Line 135: @@
 Model.A[id=38]
 </code>
+__Why:__
+First of all in this case we know what type of parent we are looking for so the first Node is an A but we do not care about the edge and therefore we can use the ''%%-->%%'' term in the pattern which means all edges are possible.
 </hidden>
@@ Line 144: / Line 162: @@
 </code>
+__Why:__
+Same as above but only for branch edge.
 </hidden>
@@ Line 168: / Line 190: @@
 Model.A[id=40]
 </code>
+__Why:__
+Now we start at a C because we know at some point above our A there is suppose to be a C, moreover we know that the type of edge does not matter so we can use ''%%-->%%''. Finally we do not only look for the direct connection but for a range of connections this can be done by ''%%()*%%''.
 </hidden>
@@ Line 194: / Line 221: @@
 </code>
+__Why:__
+This is similar to the one above only that we have to make sure that the first B and the second B are not the same Node, To do so we use the (-->)+ pattern, which test any range of connections as well but with at least one edge.
 </hidden>
@@ Line 217: / Line 247: @@
 Model.D[id=41]
 </code>
+__Why:__
+This follows the same concepts as before only with more than two nodes, if you want you can add as many as you want in a row like this.
 </hidden>
@@ Line 240: / Line 274: @@
 </code>
+__Why:__
+If you don't care about the type of nodes but only the edges you can just skip the nodes in between. Only the first and the last place have to be a Node.
 </hidden>
@@ Line 259: / Line 296: @@
 Model.B[id=33]
 </code>
+__Why:__
+  - If you want to combine several conditions in a query you can concatenate them using the comma.
+  - The '/>' edge describes a decomposition edge.
+  - The differences in the two queries are only to highlight the different possibilities.
 </hidden>
@@ Line 281: / Line 324: @@
 Model.A[id=40]
 </code>
+Besides the pattern of edges and nodes, it is also possible to add concatenate boolean conditions, if they are added in brackets (). In this case the boolean condition is actually the [[:groimp-platform:xl-builtin-methods|XL builtin method]] empty, which returns true if no the query inside does not find any match.
 </hidden>
+**12. Get all the first B's after the A's**
+<hidden answer>
+__In a Context:__
+''%%((* A (-->)+ : (B) *))%%''
+''%%((* A -minDescendants-> B *))%%''
+</hidden>
+===== OOP Queries =====