Bug in Fragments relations?

[ynnob]

Hey i tried migrating to "@thatopen/fragments": "3.4.5" and encountered some problems but i am struggeling to pinpoint them exactly.

Since the last fragment and web-ifc 0.77 version the generated relations in the fragment schema seems to be wrong and also seem to create recursive loops that were not there before. (This can either be a error in my software or the updates introduced a bug)

You can also see this in your own example. When you try to open the attached fragment i converted using 0.77 web-ifc and fragments 3.4.5 package the Items Data will also throw a StackOverflow.

https://thatopen.github.io/engine_ui-components/examples/ItemsData/

index-6HcFeNjn.js:1751 Uncaught (in promise) RangeError: Maximum call stack size exceeded
    at Set.add (<anonymous>)
    at t (index-6HcFeNjn.js:1751:239)
    at t (index-6HcFeNjn.js:1751:258)
    at t (index-6HcFeNjn.js:1751:258)
    at t (index-6HcFeNjn.js:1751:258)
    at t (index-6HcFeNjn.js:1751:258)
    at t (index-6HcFeNjn.js:1751:258)
    at t (index-6HcFeNjn.js:1751:258)
    at t (index-6HcFeNjn.js:1751:258)
    at t (index-6HcFeNjn.js:1751:258)

Repro:
Open the .frag

ifc_and_frag_example.zip

example in the Demo and select the first window like in the screenshot.

Off-Topic:
I also noticed that in this new version of the flatbuffers schema my logic for loading the Pset information for example stopped working. I do not claim that this code was a perfect port to c# yet but it worries me a bit to see this breaking. Are you planning on keeping the schema backwards compatible? I think you removed the table Alignment for example when you release the edit api. Currently i am not sure how we should handle such schema changes because we normally keep the fragment files generated in older versions.

Cheers!

[ynnob]

I think the problems might me partly related to the changes you announced in this issue:
ThatOpen/engine_fragment#176 (comment)

i noticed changing DefinesOcurrence to DefinesOccurrence currently breaks all of our old models since the recursive getItemData will not "return early" as before.

[ynnob]

Ok so the issue seems to be in engine_ui-components and not in the engine_fragment itself.
Can this issue be moved?

[agviegas]

Fixed in @thatopen/ui-obc@3.4.2 and @thatopen/ui@3.4.1, both being uploaded to npm now.

The bug was on the consumer side. After the IFCRELDEFINESBYTYPE rename in engine_fragment, type entities started showing up under IsDefinedBy alongside PSets, so the ItemsData template expanded them recursively into every sibling instance. With getItemRow sharing cached row references across parents, the row tree handed to bim-table ended up cyclic and blew the stack.

Three small changes in template.ts: rename the dead DefinesOcurrence key so back-pointers actually short-circuit, add ObjectTypeOf: { attributes: false, relations: false } to stop the type → siblings fanout, and return a shallow placeholder on getItemRow cache hits so the same node can't form a cycle.

On the schema side, sorry about the breakage. We try hard to avoid breaking changes to the .frag format, but the DefinesOcurrence typo slipped through and we wanted to fix it before it hardened any further. Two options for your existing files: reconvert with the current importer, or use the Edit API to rename the relation in place without a full reconvert. If you think the policy or migration story needs more discussion, feel free to open an issue on engine_fragment. Closing this one. Nice debugging.