View source | View content page | Page history | Printable version   

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().


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


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.


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.

Retrieved from ""

This page has been accessed 614 times. This page was last modified on 10 May 2019, at 09:20. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.