Limitations to usage of composite-type attributes





This article describes the standards that apply to the usage of composite-type attributes. All of the listed recommendations are mandatory unless noted otherwise.

This recommendation is optional

1.1. Composite-type attributes used in join, filter, and order conditions must include reference types only (CatalogRef, DocumentRef.[…] and so on). We recommend that you do not include nonreference types, such as String, Number, Date, UUID, Boolean, or ValueStorage.

If your queries do not comply with this recommendation, their performance might be significantly reduced. This recommendation is based on the specifics of physical storage of composite-type attributes in DMBS table columns.

1.2. In some cases you can use the following approach for fulfilling this recommendation:

An example document has the Address composite-type attribute where the composite type includes a reference to the Contacts catalog and a string for storing custom addresses entered by users. Instead, create the CustomAddresses catalog with the Address string attribute. Adding items to this catalog should be performed automatically when the document is written, without drawing user attention to this. You can use a scheduled job to remove catalog items that are no longer needed.

2.1. Do not use AnyRef, CatalogRef, DocumentRef, and similar composite types for typed metadata objects stored in the infobase. Specify the types of typed objects explicitly.

Universal algorithms intended for processing reference objects of various types are an exception to this rule.

2.2. If a composite type is widely used in objects belonging to a specific subsystem or in the entire configuration, we recommend that you use defined types.


Comments
0
Add comment