Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0035458Openbravo ERPA. Platformpublic2017-03-09 08:332017-03-10 14:28
vmromanos 
platform 
urgentminoralways
closedno change required 
5
 
 
Core
No
0035458: com.openbravo.test.integration.erp.modules.ci.Upgrade_FS fails with function index
I have defined a multi-column index on the FIN_PAYMENT table which includes a function and works fine in both Oracle and Postgres:

      <index name="FIN_PAYMENT_BPARTNER_CREDIT" unique="false">
        <index-column name="C_BPARTNER_ID"/>
        <index-column name="functionBasedColumn" functionExpression="OBEQUALS(GENERATED_CREDIT,USED_CREDIT)"/>
      </index>



When I send the patch to try, the job try-upgrade-pgsql fails with the following error (attached screenshot):

org.apache.ddlutils.model.ModelException: The index FIN_PAYMENT_BPARTNER_CREDIT in table FIN_PAYMENT references the undefined column functionBasedColumn


https://ci.openbravo.com//job/try-upgrade-pgsql/5297/ [^]

Apply the patch attached in 0033581
Run ant smartbuild -Dlocal=no. Verify the index is properly added to the database
Set core as indevelopment.
Export database. Verify the index is properly exported.
Send the changeset to try, or run Upgrade_FS test locally. The error in the attached screenshot is raised.
The index works fine in Oracle and PostgreSQL. It is properly applied and the export database works fine.

It seems the problem is only in that test, so probably only necessary to fix it.
No tags attached.
related to feature request 00301793.0PR15Q4 closed AugustoMauch DBSourceManager support indexes with functions 
related to design defect 0035481 acknowledged platform check local changes installing modules thorough MMC can fail 
blocks defect 00335813.0PR17Q2 closed vmromanos slow defaults retrieval in add payment 
png upgrade_FS.png (54,211) 2017-03-09 08:33
https://issues.openbravo.com/file_download.php?file_id=10543&type=bug
png
Issue History
2017-03-09 08:33vmromanosNew Issue
2017-03-09 08:33vmromanosAssigned To => platform
2017-03-09 08:33vmromanosFile Added: upgrade_FS.png
2017-03-09 08:33vmromanosModules => Core
2017-03-09 08:33vmromanosTriggers an Emergency Pack => No
2017-03-09 08:34vmromanosRelationship addedblocks 0033581
2017-03-09 08:43vmromanosDescription Updatedbug_revision_view_page.php?rev_id=14752#r14752
2017-03-09 08:43vmromanosSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=14754#r14754
2017-03-09 11:05alostaleNote Added: 0094865
2017-03-09 11:06alostalePrioritynormal => urgent
2017-03-09 11:06alostaleSeveritymajor => minor
2017-03-09 11:06alostaleStatusnew => acknowledged
2017-03-10 09:39alostaleRelationship addedrelated to 0030179
2017-03-10 14:22alostaleRelationship addedrelated to 0035481
2017-03-10 14:24alostaleStatusacknowledged => scheduled
2017-03-10 14:28alostaleNote Added: 0094920
2017-03-10 14:28alostaleStatusscheduled => closed
2017-03-10 14:28alostaleResolutionopen => no change required

Notes
(0094865)
alostale   
2017-03-09 11:05   
The failure occurs if
  1. In a version previous to 15Q4 (where function indexes where not supported)
  2. Core is updated through obx file and this update includes any function based index
  3. Before rebuilding the system any other module is tried to be updaed/installed via obx

It happens when trying to check local changes in DB, it tries to read them with old dbsm (which is already loaded in classpath) but the files in src path are the new ones as they were deployed on step 2. Dbsm is not able to read new obx files.

Updating several modules through obx without rebuilding and having updated core before than others is a rare situation. It can be prevented by not checking for local changes when core is detected to be updated but not rebuilt.

In any case, even if prevented, the code that's executed is the old one (15Q4's in this case), so the fix won't be effective till the base version is at least the one including it. In this case the test needs to be modified so that core obx is installed after the rest.
(0094920)
alostale   
2017-03-10 14:28   
* Workarounded in try CI try-upgrade-pgsql by upgrading from 15Q4 when DBSM already supports this functionality so it is able to read new model.
* int CI shouldn't require any modification as it upgrades from the latest tag available which is already after 15Q4
* A proper fix in product should be done by 0035481