Skip to main content

One post tagged with "migration"

View All Tags

Expanders 5.19.0

· 4 min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

This version of Expanders is quite impactful. It has a breaking change that could potentially affect several projects if they did not apply the NS theory correctly. This change is the removal of the detailed constructor in the projection POJO classes. We carefully considered the impact of this change and this topic describes the motivation for that and other changes.

Resources​

The expansion resources below provide Expanders 5.19.0.

ResourceVersion
Expanders5.19.0
nsx-default-stack2023.3.0
rest-jaxrs-stack3.9.0

Changes and improvements​

Removal of detailed constructor​

The projection POJO classes such as <dataElement>Details and <dataElement>Info have always had two constructors. The primary constructor is the constructor with no arguments. There was however also a secondary constructor with the database id and all fields of the projection as arguments. We have now removed the secondary constructor, as there is no technical reason for this to exist anymore.

The reason for removing the secondary constructor is that it violates Data Version Transparency, the first theorem of the NS theory. This theorem states that a changes in a data structure should not affect processing functions that consume them. This constructor, though generated by Expanders, would change whenever the relevant projection or fields in the DataElement change.

Example
Anti-Pattern

Imagine you have a DataElement with two fields:

The Expanders would generate a Details projection POJO with constructor(id: Long, name: String, value: String). This could've been used in multiple places to create an object of the POJO:

MyElementDetails myElement = new MyElementDetails(0L, "some name", "and a value");
...
CrudsResult<Void> result = createMethod(context.withParameter(new MyElementDetails(0L, "please don't", "do this")));

  • We now change the DataElement by adding a field:

    Now the detailed constructor becomes constructor(id: Long, name: String, value: String, anotherValue: Long) and every piece of code where it was used previously has to be updated. This is the textbook definition of a combinatorial effect.

  • Even worse would be if the order of the fields change:

    Now all code where the constructor is used will still compile correctly. The behavior will change completely at runtime.

The legacy option legacy.projectionDetailedConstructor.reenable was added to re-enable the old behavior where the secondary constructor was generated. This option will expire on the 1st of September 2023.

Pruning deprecated imports​

Some expanders still contained some deprecated imports for code that was reworked or removed. These have now been removed, so the relevant classes could be deprecated or removed in nsx-runtime.

In version 5.16.0 of Expanders, we removed several expired legacy options. One such option was legacy.searchDataRefMethods.reenable. All related functionality has been removed from the expanders. As such, all related classes have now been removed from nsx-runtime in version 2023.0.0. The remaining related imports have been removed from all expanders for the following classes:

  • net.democritus.support.ejb3.SearchDataRefToSearchDetailsMapper
  • net.democritus.support.Paging
  • net.democritus.sys.SearchDataRef

In 2020 the implementation of the FileUploadFeature, used to upload files through the generated UI, was improved and imports for two now deprecated classes in nsx-runtime were left behind in the Enterer classes. These imports have now been removed, though the classes are at this time still present in nsx-runtime:

  • net.democritus.io.NioFileCopier
  • net.democritus.io.SimpleUriFormat