|
|
I was working on a unit tester as part of OFBIZ-3670. This unit tester makes use of a RollbackTestCase that starts a transaction in setup and then rolls it back in teardown. At any rate, I was a testing a method that will do a select against an entity and includes an order by clause "from_date DESC". The entities are created inside this same transaction as where I fetch them, but regardless if I changed it to "from_date ASC" derby was always returning back the records in the same order.
Here is a snippet if you do not want to apply the patch --
Timestamp date01 = UtilDateTime. nowTimestamp();
Timestamp date02 = UtilDateTime.addDaysToTimestamp(date01, 5);
getDelegator().create("Agreement", UtilMisc.toMap("agreementId", "TEST_AGMT_01", "agreementTypeId", "EULA", "description", "test01", "fromDate", date01));
getDelegator().create("Agreement", UtilMisc.toMap("agreementId", "TEST_AGMT_02", "agreementTypeId", "EULA", "description", "test02", "fromDate", date02));
...
gptList = delegator.findByAnd(entityName, UtilMisc.toMap(mainId, mainValueId), UtilMisc.toList("-fromDate"));
Am I missing something obvious here? I can't imagine this is a derby bug; but the dates look good on debugging (5 days apart) and the findByAnd definition returns back a list of two entities (with their fromDate fields properly set). If I change the "-fromDate" to just "fromDate" it makes no difference on the result.
When debugging I worked down to the generated SQL (it was not getting the values from cache) ...
SELECT AGREEMENT_ID, PRODUCT_ID, PARTY_ID_FROM, PARTY_ID_TO, ROLE_TYPE_ID_FROM, ROLE_TYPE_ID_TO, AGREEMENT_TYPE_ID, AGREEMENT_DATE, FROM_DATE, THRU_DATE, DESCRIPTION, TEXT_DATA, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP FROM OFBIZ.AGREEMENT WHERE (AGREEMENT_TYPE_ID = ?) ORDER BY FROM_DATE DESC
For now I commented out my assertion that I am getting back the exepected GenericValue so that the unit test passes; but in reality it is not returning the "latest" as it is designed to do.
|
Locked
