mirror of
https://github.com/zadam/trilium.git
synced 2025-06-06 18:08:33 +02:00
some explanation on mirror relations
parent
46303d7c86
commit
c2a93cfb77
@ -7,8 +7,10 @@ To export ENEX file, you need to have desktop version of Evernote (i.e. not web/
|
|||||||
|
|
||||||
Once you have ENEX file, you can import it to Trilium. Right click on some note (to which you want to import the file), click on "Import" and select the ENEX file.
|
Once you have ENEX file, you can import it to Trilium. Right click on some note (to which you want to import the file), click on "Import" and select the ENEX file.
|
||||||
|
|
||||||
|
After importing the ENEX file, go over the imported notes and resources to be sure the import went well and you didn't lose any data.
|
||||||
|
|
||||||
## Limitations
|
## Limitations
|
||||||
|
|
||||||
All resources are created as note's attachments.
|
All resources (except for images) are created as note's attachments.
|
||||||
|
|
||||||
HTML inside ENEX files is not exactly valid so some formatting maybe broken or lost. You can report major problems into [Trilium issue tracker](https://github.com/zadam/trilium/issues).
|
HTML inside ENEX files is not exactly valid so some formatting maybe broken or lost. You can report major problems into [Trilium issue tracker](https://github.com/zadam/trilium/issues).
|
||||||
|
@ -19,3 +19,13 @@ Attribute is always name-value pair where both name and value are strings.
|
|||||||
In the above picture you can see two labels - tag and todoDate with some values. But below them you can notice again tag and todoDate attributes, but now of type "Label definition". These "definition" attributes define how the "value" attributes should behave.
|
In the above picture you can see two labels - tag and todoDate with some values. But below them you can notice again tag and todoDate attributes, but now of type "Label definition". These "definition" attributes define how the "value" attributes should behave.
|
||||||
|
|
||||||
So there's one attribute for value and one for attribute. But notice how definition attribute is [[Inheritable|Attribute inheritance]], meaning that it's also applied to all descendant note. So in a way, this definition is used for the whole subtree while "value" attributes are applied only for this note.
|
So there's one attribute for value and one for attribute. But notice how definition attribute is [[Inheritable|Attribute inheritance]], meaning that it's also applied to all descendant note. So in a way, this definition is used for the whole subtree while "value" attributes are applied only for this note.
|
||||||
|
|
||||||
|
### Mirror relation
|
||||||
|
|
||||||
|
Some relations always occur in pairs - my favorite example is on the family. If you have a note representing husband and note representing wife, then there might be a relation between those two of `isPartnerOf`. This is bidirectional relationship - meaning that if a relation is pointing from husband to wife then there should be always another relation pointing from wife to husband.
|
||||||
|
|
||||||
|
Another example is with parent - child relationship. Again these always occur in pairs, but in this case it's not exact same relation - the one going from parent to child might be called `isParentOf` and the other one going from child to parent might be called `isChildOf`.
|
||||||
|
|
||||||
|
Relation definition allows you to specify such "mirror relation" - for the relation you just define you specify which is the mirror relation. Note that in the second example we should have two relation definitions - one for `isParentOf` which defines `isChildOf` as mirror relation and then second relation definition for `isChildOf` which defines `isParentOf` as mirror relation.
|
||||||
|
|
||||||
|
What this does internally is that whenever we save a relation which has defined mirror relation, we check that this mirror relation exists on the relation target note. Similarly when we delete relation, we also delete mirror relation on the target note.
|
Loading…
x
Reference in New Issue
Block a user