Private storePrivate touchedThe set of IDs that the synchronizer has seen in its lifetime. fir uses this property to
determine which elements are safe to delete after synchronizing.
Sync#trim
Private cutRemove key-value pair tag from an element' JSON properties. If the key does not exist, this is a nop.
Given a fir element, fetch its external source aspect from the iModel.
Optional aspectOptional elementInsert fir's representation of a branch in an iModel into the iModel. Its ID is returned.
If the branch already exists fir will not attempt to insert it again. I like to think of
it like the shell program touch.
Private putPrivate putPrivate putNote that neither Models nor Aspects may be the source nor target of relationships in the link table, and therefore Models and Aspects cannot be involved in relationships with properties or relationships with (..) multiplicity.
The Relationship type represents link-table relationships.
Sync fir's representation of a branch in an iModel with the iModel. If the external source
aspect of the element has changed, the element will be updated. This function will also
insert all of the dependencies of the element if its to function is correct.
Private syncPrivate syncBecause we can only attach external source aspects to elements, a model does not have information that anchors it to the source document. In BIS speak, this is provenance. Thus, we only update the model if its modeled element has changed.
Sync#sync
Private syncPrivate tagTag an element with a key-value pair in its JSON properties. If the key already exists, it will be written over.
Private toPrivate toThis mapping function doesn't look like the rest, because its first parameter is the ID of the element that owns the external source aspect. This is because we've reversed the dependency in our element type compared to the iTwin type. Our element type refers to the aspect, while iTwin's aspect type refers to the element, just like the BIS navigation property. Thus, there's no way to resolve the BIS dependency with only the aspect; we can't traverse backwards from our aspect type to our element type.
This design decision also means we can't use to functions with aspects, because we'd have
to supply the ID of the owning element.
Aspects are only allowed as the source of relationships behind navigational properties, or as the target of element-owns-aspect relationships.
Here's my source for that quote, straight from Casey.
We're already handling the latter, and but I think the former means that aspects are allowed to have navigation properties, which will not be supported until the iTwin APIs allow you to locate the ID of an aspect you've inserted. Then we'll have to decouple the aspect type from the external aspect type, and make it point to the element, and not vice versa.
Given a subtree of the iModel, delete any elements and models that have not been seen by
the synchronizer and whose child elements have not been seen. Note that fir uses
put to find or insert the branch, so the argument will never be deleted.
This code is expected to be replaced by
ElementTreeDeleter
when it is merged into the iTwin libraries. This implementation does not defer the deletion
of definition elements; it trades efficiency for correctness, because I don't know how the
backend processes different classes of definition elements when deleteDefinitionElements
is called.
Sam Wilson's comments if you're interested why this isn't totally trivial.
deleteDefinitionElementsdoes not preserve the order that you specify, and it does not process children before parents.
What about deferring definition elements until we encounter a definition model, and
then pass its immediate children? How does the backend respond to DefinitionGroup and
DefinitionContainer?
Private trimGenerated using TypeDoc
Stores provenance information for relationships.