You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/tutorials/0.read_write.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,18 +22,18 @@ The file given in input can be either a `.mtg`, `.csv`, `.xlsx` or `.xlsm` file.
22
22
23
23
### Options
24
24
25
-
The function has two optional arguments to set the type used for the attributes, and the type used for the MTG field (see next section for more details). It also has a keyword argument to choose the sheet name in case you're reading an `xlsx` or `xlsm` file.
25
+
The function has one optional argument to set the type used for the MTG field (see next section for more details). It also has a keyword argument to choose the sheet name in case you're reading an `xlsx` or `xlsm` file.
26
26
27
27
#### Attributes type
28
28
29
-
The type used for the attributes should be a `NamedTuple`-alike or a `Dict`-alike type. Here is a more in-depth recommendation, use:
29
+
Attributes are stored using the columnar backend (`ColumnarAttrs`) by default.
30
30
31
-
-`NamedTuple` if you don't plan to modify the attributes of the MTG, *e.g.* to use them for plotting or computing statistics...
32
-
-`MutableNamedTuple` if you plan to modify the attributes values but not adding new attributes very often, *e.g.* recompute an attribute value...
33
-
-`Dict` or similar (*e.g.*`OrderedDict`) if you plan to heavily modify the attributes, *e.g.* adding/removing attributes a lot
31
+
This backend keeps one typed table per symbol and is optimized for repeated traversal and attribute retrieval. In practice:
34
32
35
-
!!! note
36
-
If you don't know what to use, just use the default.
33
+
- users can still create nodes with `Dict`/`NamedTuple`-like attribute inputs;
34
+
- those inputs are converted to the columnar representation when nodes are attached to an MTG.
35
+
36
+
So for most workflows, there is no extra option to choose here: use the default.
Copy file name to clipboardExpand all lines: docs/src/tutorials/2.descendants_ancestors_filters.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,7 +54,9 @@ The previous notations are both equivalent to:
54
54
node_attributes(node_5)[:Length]
55
55
```
56
56
57
-
But we strongly recommend to avoid this last notation. First, in our case the attributes are stored in a Dictionary (Dict, the default), so we access their values using the Dict notation: `node_attributes(node_5)[:Length]`. But if the attributes are stored as a NamedTuple-alike structure, we must use the dot notation instead: `node_attributes(node_5).Length` (see [Attributes type](@ref) for more details). Second, the attributes of the nodes are not stored in the structure returned by `node_attributes`, so updating the value of an attribute using this notation does not update the value in the MTG. This is a common mistake that can lead to very hard-to-debug issues.
57
+
`node_attributes(node_5)` returns the node attribute container view for this node (columnar backend by default), so reading and writing through it does update the MTG.
58
+
59
+
However, we still recommend the higher-level APIs (`node[:attr]`, `attribute(node, :attr)`, and `attribute!(node, :attr, value)`) because they are clearer and keep user code backend-agnostic.
58
60
59
61
That is why the package implements the more generic `node_5[:Length]` notation that works with any structure used for the attributes, which helps develop more generic code.
0 commit comments