Change ElementProps acquisition to getInstance

[6ar8nas]

This changes how we fetch ElementProps from the nativeDB. It allows bypassing the creation of a DgnElement on the native side and various json mapping adapters, which should result in both more accurate DB data representation and in some cases better Elements API performance (as explained in iTwin/imodel-native#782) by using InstanceReader for converting the data straight to an already parsed object.

To support this, a mapping function has been drafted that would allow all consuming applications to use the getInstance without the need to match the JSON representation to the accurate ElementProps extending interface.

Closes iTwin/itwinjs-backlog#1153

[pmconne]

iModel-native PR: iTwin/imodel-native#688

Instructions for correctly linking your PRs. Don't include "PR", and I'm not sure if it's case-sensitive.

[6ar8nas]

/azp run iTwin.js

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[6ar8nas]

Currently blocked by iTwin/itwinjs-backlog#1162

[6ar8nas]

more accurate DB data representation

Can you be more specific?

We would be returning data as stored in our database without layers of further mapping on imodel-native side. This would move the business/itwinjs-core logic from imodel-native to itwinjs-core itself and get the data straight from the DB without all of those adaptors.

This would only be the first part of similar efforts, with insert/update to follow thereafter, ultimately aiming to use the imodel-native data objects as the DTOs without the need to always map all of the data stored in the database to an itwinjs-core interface on imodel-native side already.

considerably better Elements API performance

Have you measured this?

iTwin/imodel-native#782 has measured it with the improvement in big actually used datasets varying between -8% and +91%.

[pmconne]

It allows bypassing the creation of a DgnElement on the native side and various json mapping adapters, which should result in both more accurate DB data representation

Have you verified the "more accurate representation" claim? Are you taking into account data fix-up/normalization that occurs during element loading such as iTwin/imodel-native#820 or this?

[6ar8nas]

It allows bypassing the creation of a DgnElement on the native side and various json mapping adapters, which should result in both more accurate DB data representation

Have you verified the "more accurate representation" claim? Are you taking into account data fix-up/normalization that occurs during element loading such as iTwin/imodel-native#820 or this?

We are taking that into account. This just changes the mapping place from C++ backend, to an itwinjs-core/common function, as per the second link, that's needed in a restricted format only in frontend.

[MichaelSwigerAtBentley]

@ColinKerr @khanaffan The new tryGetElementJson() logic does not seem to be returning null valued iModel Element Addresses. Is this expected behavior or a regression? There is a test failing that expects a null valued address to be returned.

[MichaelSwigerAtBentley]

Related issue: https://github.com/iTwin/itwinjs-backlog/issues/1403