0008801: Default values in reference data - Openbravo Issue Tracking System

Notes
(0015857) psarobe (manager) 2009-04-28 15:52	Martin, Should be this issue fixed in 250mp1?

(0015896) mtaal (manager) 2009-04-29 08:30	No in 2.60 (see the target version). gr. Martin

(0016030) mtaal (manager) 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

Issue History
Date Modified	Username	Field	Change
2009-04-28 12:21	alostale	New Issue
2009-04-28 12:21	alostale	Assigned To	=> mtaal
2009-04-28 12:21	alostale	Regression testing	=> No
2009-04-28 12:35	alostale	Description Updated
2009-04-28 15:52	psarobe	Note Added: 0015857
2009-04-28 15:52	psarobe	Status	new => feedback
2009-04-29 06:25	pjuvara	version	=> 2.50
2009-04-29 08:30	mtaal	Note Added: 0015896
2009-04-29 16:54	psarobe	Status	feedback => scheduled
2009-04-29 16:54	psarobe	fix_in_branch	=> pi
2009-05-04 23:11	mtaal	Note Added: 0016030
2011-05-23 13:24	mtaal	Target Version	3.0MP0 => 3.0MP2
2011-05-23 13:24	mtaal	fix_in_branch	pi =>
2011-06-22 20:29	dmitry_mezentsev	Target Version	3.0MP2 => 3.0MP3
2011-08-31 09:47	mtaal	Target Version	3.0MP3 => 3.0MP4
2011-09-07 13:40	mtaal	Type	defect => feature request
2011-09-07 13:41	mtaal	Target Version	3.0MP4 => 3.0MP9
2011-11-15 10:29	iperdomo	Target Version	3.0MP9 =>
2016-10-21 11:03	mtaal	Status	scheduled => closed
2016-10-21 11:03	mtaal	Resolution	open => out of date
2016-10-21 13:17	mtaal	Tag Attached: MT_closed_out_of_date
2016-10-21 14:08	mtaal	Assigned To	mtaal => platform
2016-10-21 14:09	mtaal	Status	closed => new
2016-10-21 14:14	mtaal	Tag Detached: MT_closed_out_of_date
2022-02-01 08:09	alostale	Assigned To	platform => Triage Platform Base

Relationships [ Relation Graph ] [ Dependency Graph ]