|
(0016030)
|
|
mtaal
|
|
2009-05-04 23:11
|
|
Added transcript of emails:
Hi Asier,
A bit late reaction to this email...,
Currently for the data access layer default values are applied when an object is instantiated. So for primitive types, as long as the mandatory column has a default value defined in the AD then adding mandatory colums can work (partially, see next remark). However, this solution does not work for mandatory reference properties (foreign keys). In addition default values are difficult to combine with unique constraints on primitive valued columns.
In future versions of Openbravo we could add like a pre-process script for modules which tries to set sensible data for mandatory non-set columns during import of reference data. The same type of script (ClientImportProcessor) is currently used during the import of a client. The script being used can be made configurable through an option or something.
For the rest I agree that this is not an urgent issue at the moment, let's not add mandatory columns.for now and re-visit this topic for 2.60 (using a pre-process script or other smart solution). For 2.60 we need to be sure to involve the functional development teams that they should be aware of this issue when adding new mandatory columns to the application.
gr. Martin
Asier Lostalé wrote:
> Hi,
>
> This morning we discussed about whether model API should allow addition of new mandatory columns. Because of the repercussions these additions could have there are two different cases:
>
> 1. Addition in non-application dictionary tables: This case shouldn't have big problems, the only restriction would be that the column should have an onCreateDefault value (to populate existent data in the instance) and a default value (to allow backwards compatibility for methods doing insertions not taking into account the new column). This case should work with the current implementation. But we have discovered an issue [1] that could make modules with referencedata not to work properly (additionally we should check the associated column in AD has a default value).
>
> 2. Addition in application dictionay tables: This case affects to modules. Let's suppose we add a mandatory column in ad_window table. All modules containing data in ad_window wouldn't have that value in the xml files. With the current implementation when updating a instance with modules adding values to ad_window table the effect would be, the column would be added but as the xml files wouln't have info for the column a null value would be added when importing data. This could be solved by DBSM when updating database adding the onCreate default value to those columns that are new and are not in the module. But even doing that the next update.database would not detect that columns as new so it would try to insert null values in that columns. That would be prevented exporting all modules after updating database, but as modules might not be owned by the instance that's not a valid solution, even more, if a new module is installed after that it would try to insert null values. Thus we don't have any valid solution for this case.
>
> Apart of all this, a minor version should be for stabilization, this is bug fixing but not adding new features. I think there should not (many) bugs adding new columns, thus I don't think it is very worth to try to solve these issues. My proposal is not to allow by the moment to add any mandatory column. What do you think?
>
>
> [1] https://issues.openbravo.com/view.php?id=8801 [^]
> _______________________________________________
> team.platform mailing list
> team.platform@openbravo.com
> http://list.openbravo.com/mailman/listinfo/openbravo.com.team.platform [^]
>
--
With Regards, Martin Taal
Openbravo
M: +31 6 288 48 943
@: martin.taal@openbravo.com
Skype: martintaal
Openbravo Headquarters:
P: +34 93 27 25 947
F: +34 93 27 25 905
Address: Edificio Slan, Planta 2a, Landaben, Calle J, 31012 Pamplona, Navarra, Spain
Mailing address: PO Box 5117, 31010 Pamplona, Navarra, Spain |
|