UI: Fix performance of getting subject models in Models Tree

[grigasp]

Fixes itwin/itwinjs-backlog#79

Doing the join in a single query takes up to a minute in the problematic iModel. Doing 2 separate queries and joining them on the frontend takes up to 200 ms.

[grigasp]

@Mergifyio backport release/2.19.x

[grigasp]

@Mergifyio backport release/3.2.x

[mergify]

backport release/2.19.x

🟠 Waiting for conditions to match

• merged [:pushpin: backport requirement]

[mergify]

backport release/3.2.x

🟠 Waiting for conditions to match

• merged [:pushpin: backport requirement]

[mergify]

backport release/3.2.x

✅ Backports have been created

• #3678 UI: Fix performance of getting subject models in Models Tree (backport #3666) has been created for branch release/3.2.x

[mergify]

backport release/2.19.x

✅ Backports have been created

• #3679 UI: Fix performance of getting subject models in Models Tree (backport #3666) has been created for branch release/2.19.x

[diegoalexdiaz]

I've noticed that the "PhysicalPartition.Model.Content" Json name changes per type of Partition. That is, it can also be "SpatialLocationPartition.Model.Content" or "GeometricPartition3d.Model.Content". It seems the latter two will be missed by the "queryModels" ECSQL above.

I've also seen such piece of Json is not written by all connectors. At least the IFC and Revit connectors don't write it. Maybe only the dgn connectors do. It seems such piece of Json drives some "isHidden" attribute later on.

I believe we should revisit the reasons driving the introduction of such piece of Json and corresponding UX behaviors. Since it is not supported by all connectors, and it has problems with multiple kinds of partitions, it looks to be rather the source of bugs and inconsistencies in the UX.

cc: @grigasp

[swwilson-bsi]

IIRC The BIS working group recommended the current design. The goal was to add a hint to a Subject element so that presentation rules could know what it is for and how or if to display it. That was preferred to adding an IsPrivate or IsHidden property to the Subject class.

We only need presentation hints like this because connectors create Subjects that are not relevant to the user.

[grigasp]

We only need presentation hints like this because connectors create Subjects that are not relevant to the user.

We have so many problems because of the fact that Subjects serve multiple purposes... And, sadly, it seems we're not going to have a concept that we could directly use for creating the hierarchy. Because of that, we have a project to remove the Subjects hierarchy from the Models Tree altogether. The project was on hold lately, I hope we can revive it soon.

[grigasp]

BTW, turns out querying the PhysicalPartition.Model.Content was unnecessary - here's a PR to remove it: #3697.

It's still used when creating the hierarchy, though. There we use PhysicalPartition.Model.Content and GraphicalPartition3d.Model.Content. Now you're saying we're missing a few others with a possibility that there might be even more than that. Sounds like the list is not definite, because we'd get a new attribute every time a a new subclass of InformationPartitionElement is introduced.

@swwilson-bsi says that the sole purpose of this flag is to help create the Models Tree. Then I'd question what's the point of creating so many different attributes and making it difficult to capture all of them for the only component that uses them.

And just to explain what the attribute does in the Models Tree... When an InformationPartitionElement has this attribute, we don't show its Model node and instead show Categories directly under Subject node. So not capturing the attribute would mean the Model node is displayed.