Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0008900Openbravo ERPA. Platformpublic2009-05-05 11:182011-09-07 13:36
mtaal 
mtaal 
normalminorhave not tried
closedfixed 
5
pi 
pi3.0MP0 
Core
No
0008900: Inconsistencies between database default values and application dictionary default values
Apparently there is some lack of consistency in the default values. There are some columns that take default values at database level, but have no default value set at AP level. This makes causes some trouble when working with DAL, as some parameters need to be defined although it should be possible to leave them blank as they have a default value at database level. Example: qtyreserved in c_orderline. Database level: default=0. AP no default set.

A first step could be to add a test to check/validate the differences in default value setting between the database and application dictionary.
250mp2
related to defect 0009966 closed balamurugan Boolean values of DB should be replaced by AD ones. 
related to defect 0009967 closed balamurugan AD literals default values should not be quoted 
depends on defect 0009050pi closed mtaal Default value in database and application dictionary differ, they need to be the same 
depends on defect 0009051pi closed rafaroda Finance: Default value in database and application dictionary differ, they need to be the same 
depends on defect 0009052pi closed rafaroda MRP: Default value in database and application dictionary differ, they need to be the same 
depends on defect 0009053pi closed rafaroda Project: Default value in database and application dictionary differ, they need to be the same 
depends on defect 0009054pi closed rafaroda Common: Default value in database and application dictionary differ, they need to be the same 
related to defect 0008899 closed mtaal Column type in Application dictionary different to Database column type - UUID 
related to defect 0008897 closed AinhoaPagola Column type in Application dictionary different to Database column type - AD_Pinstance - UUID 
Issue History
2009-05-05 11:18mtaalNew Issue
2009-05-05 11:18mtaalAssigned To => mtaal
2009-05-05 11:18mtaalRegression testing => No
2009-05-05 11:20mtaalRelationship addedrelated to 0008899
2009-05-05 11:20mtaalRelationship addedrelated to 0008897
2009-05-05 12:03psarobeTag Attached: 250mp2
2009-05-05 12:04psarobePrioritynormal => urgent
2009-05-05 12:04psarobeStatusnew => scheduled
2009-05-07 10:23mtaalNote Added: 0016122
2009-05-15 16:52mtaalRelationship addedrelated to 0009050
2009-05-15 16:52mtaalRelationship addeddepends on 0009051
2009-05-15 16:53mtaalRelationship addedrelated to 0009052
2009-05-15 16:53mtaalRelationship addedrelated to 0009053
2009-05-15 16:53mtaalRelationship addedrelated to 0009054
2009-05-15 16:55mtaalNote Added: 0016392
2009-05-15 16:55mtaalRelationship replaceddepends on 0009050
2009-05-15 16:55mtaalRelationship replaceddepends on 0009052
2009-05-15 16:55mtaalRelationship replaceddepends on 0009053
2009-05-15 16:56mtaalRelationship replaceddepends on 0009054
2009-06-10 11:51mtaalPriorityurgent => normal
2009-07-20 15:56rafarodaSeveritymajor => minor
2009-07-20 15:56rafarodaRelationship addedrelated to 0009966
2009-07-20 16:05rafarodaRelationship addedrelated to 0009967
2009-07-20 16:10rafarodaNote Added: 0018426
2009-07-20 20:47mtaalNote Added: 0018435
2011-09-07 13:36mtaalNote Added: 0040793
2011-09-07 13:36mtaalStatusscheduled => resolved
2011-09-07 13:36mtaalFixed in Version => 3.0MP0
2011-09-07 13:36mtaalFixed in SCM revision => .
2011-09-07 13:36mtaalResolutionopen => fixed
2011-09-07 13:36mtaalNote Added: 0040795
2011-09-07 13:36mtaalStatusresolved => closed

Notes
(0016122)
mtaal   
2009-05-07 10:23   
Adding small remark from Antonio through email:
It is possible to get the default value for a column in dbsourcemanager, you just need to do column.getDefaultValue().
(0016392)
mtaal   
2009-05-15 16:55   
I have implemented a check in the database.validation step. There were about 20 different differences, I have reported these as issues grouped by functional group. The check is disabled until all these issues have been solved otherwise it is not possible to reenable the check.

keeping this issue open until all the other newly reported issues have been solved.
(0018426)
rafaroda   
2009-07-20 16:10   
Please notice that this differences should not be taken into account (false positives):
 -SYSDATE (in DB) and Sysdate (in AD) are logically identical (reference to
sytem date)
-'Y' (in DB) and Y (in AD) are logically identical (syntax in db requires
string literals to be quoted)
(0018435)
mtaal   
2009-07-20 20:47   
The check should be adapted to specifically test for this case:
default value set in the DB, mandatory in AD, no default value in AD
(0040793)
mtaal   
2011-09-07 13:36   
All child issues fixed
(0040795)
mtaal   
2011-09-07 13:36   
All child issues fixed