Differences

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

--- tutorials:custom_storing_node [2025/07/16 12:07] – gaetan
+++ tutorials:custom_storing_node [2025/07/16 14:33] (current) – gaetan
@@ Line 112: / Line 112: @@
 Thus, instead of storing the Nodes themselves, their id should be stored.
-For example, the project:
+For example, in the project:
 <code java >
@@ Line 127: / Line 127: @@
 public void dostuff()[
 a:A ==> B(a.getId())
-	   {mynodeid[0]=a.getId();}
+	{mynodeid[0]=a.getId();}
-	   ;
+	;
 ]
@@ Line 136: / Line 136: @@
 	println( (*A*));
 }
+</code>
+The method ''queryA()'' do not print Node A. Indeed, the Node A do not exists anymore.
+In this example, the Node A is replaced by a Node B in the main graph. Thus, should not exists anymore. But in other project, the Node A can remains in the graph. E.g.
+<code java>
+long[] mynodeid = new long[1];
+module B(long parentNode);
+module A;
+protected void init ()
+[
+	Axiom ==> A;
+]
+public void dostuff()[
+a:A ==> a B(a.getId())
+	{mynodeid[0]=a.getId();}
+	;
+]
 public void getTheNode(){
 	// Get the node from an array
-	graph().getNodeForId((mynodeid[0]));
+	println(mynodeid[0]);
+	println(graph().getNodeForId((mynodeid[0])));
 	// Get the parentNode of B
-	[b:B ::> graph().getNodeForId( b.parentNode); ]
+	[b:B ::> println(graph().getNodeForId( b.parentNode)); ]
 }
-</code
+</code>
+Here, as the Node A still is in the main graph, it is accessible with methods such as in ''getTheNode()''.
+Using the id instead of the Node to "store" the Node ensure that once the Node is moved out of the main graph, it is properly deleted. It prevents unwanted leftover artifacts in the project graph, that can pollute the XL queries.
+==== Using custom edges ====
+Relationship between objects of the graph should be stored in the graph. Thus, in the example of ''module B(A parent)'', the knowledge between A and B should be part of the graph. To keep such information it is possible to use custom edges (or edges that are not SUCCESSOR and BRANCH. e.g. REFINEMENT_EDGE, MARK_EDGE, ...).
+  * For example if B do **NOT** replace A:
+<code java>
+module A;
+module B;
+int e = Library.EDGE_0;
+protected void init ()
+[
+	Axiom ==> A F ;
+]
+public void grow()[
+	a:A ==> a B [-e->a];
+]
+</code>
+{{:tutorials:tuto_store_node_7.png?100 |Before "grow"}}
+{{ :tutorials:tuto_store_node_8.png?100 |After "grow"}}
+One the left: before the "grow" method, on the right after. On the right picture, we can see that B and A have both the SUCCESSOR edge **AND** the custom EDGE_O. In this case the additional EDGE_0 might not bring much knowledge, however, in more complex project, A and B might not be directly related. Thus, adding the edge EDGE_0 adds both the knowledge of the ''parentNode'' "attribute" and it can be used to speed up future XL queries.
+  * If B do replace A. And the relationship between B and A must exists even though A is not part of the **visible** part of the graph.
+<code java>
+public void grow()[
+    a:A ==> B [-e->a];
+]
+</code>
+will produce the graph:
+{{ :tutorials:tuto_store_node_9.png?100 |}}
-Instead of
+You can see that the Node A is still part of the main graph. It is XL query-able and reachable from B by following the edge EDGE_O. However, as the Node A is not connected to the Root by neither BRANCH, nor SUCCESSOR edge, it will not be displayed (not part of the 3d view, and raytracer).
+**Note:** In the example we used EDGE_O, there are actually 13 usable unique bit-wise edge type defined in Library: EDGE_0 to EDGE_12. But it is also possible to use any Integer as "unique" edge bit. It is still important to know that the edge bit is used for bit wise operations. Thus if the edge bit you use contains the bit SUCCESSOR, the edge will be a successor.