enhancement
critical
major
minor
minor
#25907
Layout editor: inconsistent behavior of unfold state, selection and reaction to object creation
#25951
Application tests: CheckLabeledExecutabilityOp fails to assert non-executability of literal ResKey reasons.
#25952
Model Editor: Enum default provider does not work for enum references for which singleton link storage was explicitly selected
#26002
ConfigurationItem-valued properties with format annotations may cause an attempt to create abstract config items when deserializing null values
#26012
Help editor crashes when a user has chosen a language that is not in the supported languages of the application
#26039
Gridcomponent: Display of context menu for new (transient) row object leads to UnsupportedOperationException
#26085
An attribute of type tl.model.search:Expr is not displayed in the form above a TL script editor
#26111
Context menu commands for table rows are erroneously executed on the table model when opening the context menu in the background of the table
#26153
Migration: Replay fails if string values with line breaks are contained in the dataset where a line ends with a semicolon
#26171
A TL script expression entered in a wizard template is reformatted when transferred to the final template
#26223
TL script: Under unfavorable conditions wrong parameter values when evaluating local functions
enhancement
The TL model is being used more and more frequently. As a result, it’s becoming increasingly apparent that this can lead to performance issues. This is particularly problematic when the type hierarchy is required: In such cases, each call recursively traverses the entire hierarchy up or down, and even duplicate paths are not recognized as such but are traversed multiple times.
Improvement
In particular, methods such as TLModelUtil.isCompatibleInstance(...) and getConcreteSpecializations should use a cache and avoid unnecessary overhead from the outset—such as that caused by duplicate paths in the model. The other methods in tl:TLModelUtil should also be reviewed for their optimization potential.
Usage
The cache has been integrated into `tl:TLModelUtil` and is used automatically. If, however, you need to access this cache directly, you can do so as follows: {{{#!java TLModelCacheService.get().getSubClasses(TLClass) }}}
The cache has been implemented in such a way that these calls still work even when the cache is disabled. In that case, the result is recalculated for each call, as before.
Result
As a result, the demo tests in the nightly build are now about 10% faster: 33 minutes instead of 36 minutes.
Code Migration
- Replace `TLModelUtil.calcAllSuperClasses(TLClass) ` and `TLClass.getAllSuperClasses()` with `TLModelUtil.getReflexiveTransitiveGeneralizations(TLClass)`.
- Replace `MetaElementUtil.getAllSubMetaElements(TLClass) ` with ` TLModelUtil.getTransitiveSpecializations(TLClass)`.
- Replace `MetaElementUtil.getConcreteTransitiveSpecializations(TLClass) ` with ` TLModelUtil.getConcreteSpecializations(TLClass)`.
- Replace `MetaElementUtil.getSuperMetaElements(TLClass) ` with ` TLClass.getGeneralizations()`.
- Replace `TLModelUtil.getSubMetaElements(TLClass) ` with ` TLClass.getSpecializations()`.
- ReplaceTLModelUtil.calcAllParts(TLClass) with TLClass.getAllClassParts().
- TLModelUtil.getAllGlobalClasses(TLModel) returns a Set instead of a List.
- The following methods now return immutable collections, since they retrieve values directly from the cache:
- TLModelUtil.getMetaAttributes(TLClass)
- TLStructuredType.getAllParts()
- TLClass.getAllClassParts()
Test
TestTLModelUtilPersistent has been extended to include corresponding tests. The transient tl:TLModel does not test the cache because it is only active for the persistent tl:TLModel. The correctness of the calculated values in the cache is already verified by the standard tests for the persistent TLModel. Therefore, the new tests only verify the caching mechanism itself: Is the same object actually returned on every call? And are the values returned by the cache immutable?