Add test which introduces a EntityClass that has a CA 'QueryView' and a navigation property to exercise ECReferenceTypesCache

[nick4598]

Right now the only place this cache appears to be used is cloneElementAspect.

if (sourceNavProp?.id) {
          const navPropRefType = this._refTypesCache.getNavPropRefType(
            sourceElementAspect.schemaName,
            sourceElementAspect.className,
            propertyName
          );

I believe there could never be a navigation property with an id which pointed to an Entity which had the customattribute of QueryView, but I'm not sure. My logic being that the modifiers I saw for all other examples of QueryView being used were abstract. The QueryView is built off of the elements in the database, so I assume the view itself would never be represented as an id. I suppose theres a possibility that there could be a non abstract entity with the custom attribute QueryView? Or is that somehow prevented with the way the schema is written?

I briefly tried this out by adding a base class to the testview entity in my testQueryView schema and changing the modifier from Abstract to Sealed, but then I would get

Error | ECObjectsNative | The NavigationECProperty BisCore:Element:Parent cannot be overridden by TestGeneratedClassesNew:TestView:Parent because the relationship was changed. A derived property cannot change the referenced relationship.
Error | ECObjectsNative | Failed to read class 'TestView' from schema 'TestGeneratedClassesNew'
Error | ECObjectsNative | Failed to read XML file: D:\repos\imodel-transformer\packages\transformer\lib\cjs\test\assets\TestQueryView.ecschema.xml

Are there potentially any other EC concepts that would cause this code to fail? Or are QueryViews unique?

[nick4598]

Worried about potential performance implications, if I am checking the customattributes of every relationshipClass for the queryView attribute, will that be slow? Potential optimization is to only check if the sourceType or targetType are undefined?

I imagine this is probably quite a small %age of any given transformer run, so maybe it doesn't matter?

[nick4598]

Started timing it: Info | core-backend.IModelTransformer | Checked 1444 classes for QueryView custom attribute. This took 4ms.

Its maybe overkill.

[nick4598]

@ColinKerr What is the recommended way to tell if a class is abstract or not?
Right now if targetType is undefined from calling ECReferenceTypesCache.bisRootClassToRefType[targetRootBisClass.name]; That seems like a pretty good indicator that something is abstract, because it didn't have any matches for Element, Model, ElementAspect, or Relationship. But I do worry that it isn't foolproof. What if something else went wrong to cause us to get undefined? Right now the code assumes it is an error to get undefined and throws.

private static bisRootClassToRefType: Record<
    string,
    ConcreteEntityTypes | undefined
  > = {
    /* eslint-disable quote-props, @typescript-eslint/naming-convention */
    Element: ConcreteEntityTypes.Element,
    Model: ConcreteEntityTypes.Model,
    ElementAspect: ConcreteEntityTypes.ElementAspect,
    ElementRefersToElements: ConcreteEntityTypes.Relationship,
    ElementDrivesElement: ConcreteEntityTypes.Relationship,
    // code spec is technically a potential root class but it is ignored currently
    // see [ConcreteEntityTypes]($common)
    /* eslint-enable quote-props, @typescript-eslint/naming-convention */
  };