[jira] [Updated] (OFBIZ-13742) Integration tests fail on PostgreSQL because of duplicate GL account codes and row-order assumptions

["Mridul Pathak (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-13742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mridul Pathak updated OFBIZ-13742:
----------------------------------
    Description: 
On PostgreSQL, 37 integration tests fail that pass on H2:
* {{InventoryIssuanceTestData.xml}} gives its four test GL accounts the codes 140000, 141000, 142000 and 500000, which the demo data already uses. PostgreSQL enforces the unique index {{GLACCT_UNQCD}}, so the data load fails and 35 {{inventoryissuancetests}} cases error out. H2 doesn't catch this because its datasources create unique indexes as non-unique.
* Once the data loads, {{testS3_4_ImpactPlanAudit}} fails because {{getProductionRunTaskForceIssueImpact}} loads the reallocation candidates without an order. When several reservations share one inventory item, which one gets reallocated depends on the order the database returns rows in.
* {{testDuplicateWorkEffortWithAssocsAndNotes}} reads the duplicated notes without an order and checks the first one, but the work effort has two notes at that point.

h3. Proposed fix
Give the test GL accounts unique codes. Order both reallocation-candidate queries by the reservation's {{createdStamp}}, so the oldest reservation is always reallocated first; this needs an explicit {{createdStamp}} alias in {{WorkEffortInvResAndItem}} and {{OrderItemShipGrpInvResAndItem}}, since {{alias-all}} never includes stamp fields. Check that the duplicated notes contain {{TestNote-1}} instead of relying on row order.

  was:
On PostgreSQL, 36 integration tests fail that pass on H2:
* {{InventoryIssuanceTestData.xml}} gives its four test GL accounts the codes 140000, 141000, 142000 and 500000, which the demo data already uses. PostgreSQL enforces the unique index {{GLACCT_UNQCD}}, so the data load fails and 35 {{inventoryissuancetests}} cases error out. H2 doesn't catch this because its datasources create unique indexes as non-unique.
* {{testDuplicateWorkEffortWithAssocsAndNotes}} reads the duplicated notes without an order and checks the first one, but the work effort has two notes at that point.

h3. Proposed fix
Give the test GL accounts unique codes, and check that the duplicated notes contain {{TestNote-1}} instead of relying on row order.


> Integration tests fail on PostgreSQL because of duplicate GL account codes and row-order assumptions
> ----------------------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-13742
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-13742
>             Project: OFBiz
>          Issue Type: Bug
>          Components: manufacturing, workeffort
>    Affects Versions: Upcoming Branch
>            Reporter: Mridul Pathak
>            Assignee: Mridul Pathak
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> On PostgreSQL, 37 integration tests fail that pass on H2:
> * {{InventoryIssuanceTestData.xml}} gives its four test GL accounts the codes 140000, 141000, 142000 and 500000, which the demo data already uses. PostgreSQL enforces the unique index {{GLACCT_UNQCD}}, so the data load fails and 35 {{inventoryissuancetests}} cases error out. H2 doesn't catch this because its datasources create unique indexes as non-unique.
> * Once the data loads, {{testS3_4_ImpactPlanAudit}} fails because {{getProductionRunTaskForceIssueImpact}} loads the reallocation candidates without an order. When several reservations share one inventory item, which one gets reallocated depends on the order the database returns rows in.
> * {{testDuplicateWorkEffortWithAssocsAndNotes}} reads the duplicated notes without an order and checks the first one, but the work effort has two notes at that point.
> h3. Proposed fix
> Give the test GL accounts unique codes. Order both reallocation-candidate queries by the reservation's {{createdStamp}}, so the oldest reservation is always reallocated first; this needs an explicit {{createdStamp}} alias in {{WorkEffortInvResAndItem}} and {{OrderItemShipGrpInvResAndItem}}, since {{alias-all}} never includes stamp fields. Check that the duplicated notes contain {{TestNote-1}} instead of relying on row order.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)