Openbravo Issue Tracking System - Openbravo ERP
It is known that this can be worked around by redefining the affected columns in the ad. But in this case this is a logic bug fic imho it should be fixed there.
Both cases have their logic in FIC function computeColumnValues around lines 555+ 576 (2 places affected)
a.) The logic in FIC is computing combo-values for all columns in case of mode=CHANGE, when visibleProperties is null.
This can be trigger in the UI when having open a window in form fiew, then switching to another openbravo window and coming back to the first window.
This coming back to first window, does trigger a FIC call in mode=change which does not have the visibleProperties object with values.
b.) The logic in FIC is taking into account isDisplayed, isShownInGrid, isShownInStatus and if none of those are set does not compute all values of a combo for this column. However this logic does not take into account isactive flag. So having a ad_field entry with isactive=n but isdisplayeD=Y does trigger computation of the combo.
The attached patch does implement the change a.) taken into account visibleProperties==null.
Also it adds some debugging code which makes it much easier to find out why a column has it combo-values calculated without needing to go into the ad to check all the flags manually.
AMO: has a prototype patch to implement part b.) which is also refactoring the if-logic a bit as it is very hard to read in its current form.
3.) part: Another idea to improve performance for fic combo-calculation
In case of a column not being visible sometimes it still needs the combo-values calculated to get a default-value to be used on inserts.
However in this case only a single value (the final default-value is needed).
Here the potentially big memory-spike of having all millions of combo values in memory can be avoided by adapting the logic.
AMO: has also a prototype patch to implement this part 3.)
Note: for the cases triggering oom's in the client a+b are sufficient to avoid the known cases.
However part 3.) should also be very useful to reduce memory consumption in other not yet observed cases.
NOTE: This is a candidate to be backported, but should get some extra maturing first.
b.) Change logic to also take isactive into account for the part of the if related to visibility only. The second part of the if regarding default values is different and may or not need to get the same change.
In the observed case the change would only be needed for the display part which should also be the safer option as it reduces the scope of the change.
fic_prototype_change_a.diff (4,584) 2014-02-07 08:18https://issues.openbravo.com/file_download.php?file_id=6691&type=bug
fix25684Part_b.diff (3,118) 2014-02-07 12:16https://issues.openbravo.com/file_download.php?file_id=6692&type=bug
fix25684Part_3.diff (6,177) 2014-02-07 12:19https://issues.openbravo.com/file_download.php?file_id=6693&type=bug