Projects:Configurable Child OneToMany Property In Parent Entity/Specs

Current state

Currently (PR19Q2), all properties with a foreign key reference generate a one-to-many reference in the parent entity.

This makes sense from the functional point of view and it is convenient in some cases, whereas is some others does not being even dangerous.

For example, being able to retrieve order lines from an order header makes perfect sense: order.getOrderLineList(). But getting all orders, created by a business partner, which might be thousands, does not: businessParter.getOrderList().

Problems

These properties, when don't make sense, can be problematic because of the following reasons:

• Potential OutOfMemoryError. When one of those properties is invoked, the complete list of referenced child objects in loaded in JVM's heap memory, so for example businessParter.getOrderList() is potentially going to retrieve from database thousands of records and load them all in memory.
• Cluttered generated classes. For each of these properties, the DAL generated class includes a static field with its name, a getter method and a setter method. For example, in the case of BusinessParter entity, there are 46 of those properties which generate 92 methods, most of them completely useless.
• When Tomcat is started, DAL in-memory model and Hibernate model are loaded, the size of the retained heap is severely affected by all of these properties.

Fix

A new boolean property in AD_Column will be added to determine for each foreign key property whether it should or not generate a one-to-many counterpart on its parent entity.

This property will be defaulted to false (not generate a property in the parent) for new columns, and developers will need to, case by case, flag the ones they want to be generated.

Backwards compatibility

The aim of this project is to add the Platform capacity to be able to define which properties should not be generated in the parent, but it should not change the existing API.

Defaults

In order to preserve existing API, when this new column is created it will be defaulted to true (generate a property in the parent), whereas new columns will be defaulted to false.

Forced old API

As after reviewing all FK columns and reverting them not to generate properties in the parent, there might be a massive API change, a new preference in Openbravo.proerties will be available. When this preference is set, the new property will not be taken into account and all properties will be generated in parent entities regardless of their setting.

Impact in Heap

Currently, a clean Openbravo, without any additional module installed, retains up to 168MB in SessionFactory (measured with JDK11, in JDK8 this amount increases up to 220MB).

If none of these properties would be generated, retained heap would be reduced to 58MB. This is just the maximum potential, of course, there are properties that make sense and are correctly used so that cannot be removed.

Removing the select 235 Platform properties identified here, size is decreased to 158MB.