Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0009650Openbravo ERPA. Platformpublic2009-06-26 10:072009-08-19 00:00
joan 
marvintm 
urgentmajoralways
closedfixed 
30Debian Etch
2.40 
 
Core
No
0009650: Upgrade from 2.40 to 2.50MP1, foreign key changes update problem.
When you changed in ob.2.40 a foreign key for instance you create an on update cascade in any of the existing foreign-key references when you do the upgrade to 2.50MP1 following the documentation on http://wiki.openbravo.com/wiki/ERP/2.50/Upgrading_From_2.40 [^] and you reach the step

ant export.database export.config.script -Dforce=true

when it is doing

 ant export.config.script -Dforce=true

after do the

 ant export.database -Dforce=true

It fails throwing

Loading model for module. Path: /opt/upgrade/ob250up/modules/org.openbravo.upgrade.template/src-db/database/model
[exportconfigscript] org.apache.ddlutils.model.ModelException: There are multiple foreign keys in table AD_MODEL_OBJECT with the name MODELOBJECT_FK_REFERENCE
[exportconfigscript] at org.apache.ddlutils.model.Database.initialize(Database.java:786)
[exportconfigscript] at org.openbravo.ddlutils.task.DatabaseUtils.readDatabase(DatabaseUtils.java:74)
[exportconfigscript] at org.openbravo.ddlutils.task.ExportConfigScript.doExecute(ExportConfigScript.java:106)
...

The problem is the foreign key already exists on the database, and there is no update constraint, so it should drop the existing foreign key and add the new one instead of give the error.
Install ob240
DROP MODELOBJECT_FK_REFERENCE reference from table AD_MODEL_OBJECT
ADD new MODELOBJECT_FK_REFERENCE with a "on update cascade"
Try to upgrade from ob240 to ob250 folllowing the wiki http://wiki.openbravo.com/wiki/ERP/2.50/Upgrading_From_2.40 [^]

No tags attached.
blocks defect 0009776 closed rafaroda Upgrade 2.40 -> 2.50 Does not mantain the data on ma_sequenceproduct 
Issue History
2009-06-26 10:07joanNew Issue
2009-06-26 10:07joanAssigned To => rafaroda
2009-06-30 21:44iciordiaNote Added: 0017702
2009-06-30 21:44iciordiaAssigned Torafaroda => marvintm
2009-06-30 21:44iciordiaPrioritynormal => urgent
2009-07-01 09:35joanNote Added: 0017714
2009-07-01 11:11iciordiaSeveritycritical => major
2009-07-13 13:30psarobeRelationship addedblocks 0009776
2009-07-20 22:18psarobeStatusnew => scheduled
2009-07-20 22:18psarobefix_in_branch => pi
2009-07-28 11:14hgbotCheckin
2009-07-28 11:14hgbotNote Added: 0018648
2009-07-28 11:14hgbotStatusscheduled => resolved
2009-07-28 11:14hgbotResolutionopen => fixed
2009-07-28 11:14hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/53b560533be192e152b871dcc8e0da951a78796b [^]
2009-08-18 10:16plujanStatusresolved => closed
2009-08-19 00:00anonymoussf_bug_id0 => 2839882

Notes
(0017702)
iciordia   
2009-06-30 21:44   
Joan,

thanks for reporting this issue.

The problem is that your change in the constraint is identified and included in your module (using ad_exception store since you are not following naming convention). But then DBSourceManager does not manage it properly and tries to create this constraint twice instead of ignoring core one (module exceptions are meant to replace core components).

Furthermore, it would be better managed as a change included in the configuration script of your customization (right now this kind of change is not supported by configuration scripts).

I am changing the severity to urgent since you can easily work around the problem: remove the constraint from db xml files in core and build your system again, your customized constraint will be kept. The fix for this bug will be planned for next sprint.

Ismael
(0017714)
joan   
2009-07-01 09:35   
ok, thanks for the response :)

I will use the workaround until it is solved

Thanks :)
(0018648)
hgbot   
2009-07-28 11:14   
Repository: erp/devel/pi
Changeset: 53b560533be192e152b871dcc8e0da951a78796b
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Tue Jul 28 11:13:27 2009 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/53b560533be192e152b871dcc8e0da951a78796b [^]

Fixed issue 9650. Now if several foreign keys with the same name for the same table are found when doing a model merge, the last one 'prevails' (the previous ones are overwritten).

---
M src-db/database/lib/dbsourcemanager.jar
---