0.163.0 Change Notes
Breaking changes to Id64
The use of Id64 objects to represent 64-bit IDs was determined to produce measurable negative impact on both memory consumption and code execution time. This impact was amplified by inconsistencies within the iModel.js library - APIs dealing with 64-bit IDs would variously represent them as plain string
s, Id64
objects, or either through use of the type alias Id64String = Id64 | string
. Frequent conversion from one representation to another would often be required when using these APIs. The naming of some functions was also ambiguous.
To address these problems the following changes were made:
- The Id64String type alias was reduced to a simple alias for
string
. It now serves as a marker type indicating that astring
variable or function argument is expected to conform to the semantics of a well-formed 64-bit ID. - All function arguments, function return types, and class members of type
Id64
were changed toId64String
. - The Id64 class was turned into a namespace.
- Functions for validating, and interrogating
Id64String
s were added to theId64
namespace. - The code for parsing, validating, and interrogating
Id64String
s was optimized to execute more quickly. - Id64.getLow() and Id64.getHigh() were renamed to Id64.getLocalId and Id64.getBriefcaseId.
See Working with IDs for an updated overview.
The pervasiveness of 64-bit IDs in iModel.js make these changes very likely to break existing code in consumers of the iModel.js packages. To adapt such code:
- Replace all usage of
Id64
objects withId64String
. - Replace all calls to the
Id64
constructor with a call to one of the functions in Id64 returning anId64String
based on your input to the constructor:- If your input is a JSON representation of an ID - type
string | undefined
- use Id64.fromJSON. - If your input is a string, use Id64.fromString if the string is not known to already contain a well-formed ID; otherwise elide the call.
- If your input is an array of 2 numbers indicating a briefcase ID and local ID, use Id64.fromLocalAndBriefcaseIds.
- If your input is a JSON representation of an ID - type
- Replace all calls to non-static
Id64
methods with equivalent methods accepting anId64String
. - Replace calls to
equals
andareEqual
with the built-in comparison operators.
Breaking changes to Guid
To keep Id64 and Guid consistent, similar changes were done to the Guid class.
The following changes were made:
- The GuidString type alias was reduced to a simple alias for
string
. It now serves as a marker type indicating that astring
variable or function argument is expected to conform to the semantics of a well-formed GUID. - All function arguments, function return types, and class members of type
Guid
were changed toGuidString
. - The Guid class was turned into the Guid namespace.
- Functions for validating
GuidString
s were added to theGuid
namespace.
The pervasiveness of GUIDs in iModel.js make these changes very likely to break existing code in consumers of the iModel.js packages. To adapt such code:
- Replace all usage of
Guid
objects withGuidString
. - Replace all calls to the
Guid
constructor with a call to one of the functions from the Guid namespace returning anGuidString
based on your input to the constructor- In particular,
new Guid(true)
is to be replaced byGuid.createValue()
.
- In particular,
- Replace all calls to non-static
Guid
methods with equivalent methods accepting anGuidString
. - Replace calls to
equals
andareEqual
with the built-in comparison operators.
Breaking changes to RPC web server configuration
If you do not use IModelJsExpressServer to manage your backend web server, you must add a GET route that invokes WebAppRpcProtocol.handleOperationGetRequest to your express application. Cacheable RPC operations (including tile content requests) now use the HTTP GET method when configured using RpcConfiguration.
Last Updated: 08 January, 2020