Replies: 3 comments 8 replies
-
Beta Was this translation helpful? Give feedback.
-
|
Hi Nathan Would it be possible to extend the BIS Core class in order to create a class definition that you own and then use the domain handler functions that you mentioned (onInsert, onUpdate, ect)? Those functions are definable for class-specific scenarios like this. It is also potentially possible we can add this logic into the domain handlers for the BIS core classes. |
Beta Was this translation helpful? Give feedback.
-
CoPilot lied to you - all of this is happening synchronously on a single thread, though execution may pass from native to JS and back. Pardon a potentially dumb question but do the sheet numbers actually need to be stored in the iModel? Couldn't they be computed as needed? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We are having an issue with elements persisting after the transaction. We understand why, but want to:
Explain workflow:
We are trying to create an automated system to maintain a Sheet Index and its Sheet Numbers (a unique string describing a Sheet). The Sheet Index for this purpose can be thought of as an ordered filing system or a tree graph. We have a Sheet Index that acts as the root, and SheetIndexEntries make up the ordered children. SheetIndexEntries can either be a SheetIndexFolder or a SheetReference. These are both bis structures from iTwin.js Core. We have created a SheetNumberingAspect, which describes the “recipe” for the Sheet Number. The system will then traverse the ordered tree and use that recipe to calculate the Sheet Number and update the SheetReference’s Code Value.
Currently we are triggering this system to process the Sheet Index using the iModel.txns.onCommit event.
The Motivation for using onCommit
We decided on this approach for two main reasons.
We wanted a central hook for the system since there are wide, varied and not yet well-defined systems that could trigger these changes. - A central event monitoring the changes to the iModel reduces the overhead on those systems and the possibility of the SheetIndex becoming outdated.
We did consider some alternatives.
The element drives element relationship doesn’t seem to work for this case. The tree needs to be processed as a whole, meaning that driving individual elements doesn’t really work, but we have considered a few dependance graphs.
We have also considered using the class “on” event handles, such as “onInsert” or “onUpdate,” but are not sure if this is possible since we don’t own those classes outside of iTwin.js Core.
Explaining the findings around the issue for why it is unclear how this should work
During our investigation of the bug, we found a few comments implying this workflow should not work.
BESQLLite.cpp // save briefcase local values again after _OnCommit. It can cause additional changes
BriefcaseTxns.test.ts // NB: onCommit is produced after we process all changes. onModelGeometryChanged is produced during change processing.
Our theory based on these comments, reading the code, and assistance from CoPiliot is that the onCommit event is raised to the typescript level on a different thread. By the time the typescript was executed, the native code has already finalized the transaction.
While these comments reveal that this behavior was understood by the core developers at some point, we wanted to confirm this was a design decision.
Questions
CC: @Alfonso-Martello & @nimam-bentley
Beta Was this translation helpful? Give feedback.
All reactions