rzo1 commented on PR #216: URL: https://github.com/apache/openjpa/pull/216#issuecomment-6253138615
@cristof Good question, and it was the cause of the red build rather than a coincidence: the four legs started failing the moment #215 (OPENJPA-2950) was merged. The order matters, but the test had it the wrong way round. It asserted that the unrelated pending `UPDATE BULK_ITEM` precedes the candidate `SELECT`, i.e. that the query pre-flushes the whole context. After OPENJPA-2950 a query flushes only its own access path, and `BulkDeleteItem` is not on it, so the pending change now survives the candidate query and is written by the trailing flush this PR adds. The captured SQL after rebasing onto current master: ``` SELECT t0.number, t0.tenant, t0.name FROM BULK_CID_OWNER t0 WHERE (t0.name = ?) DELETE FROM BULK_CID_TAGS WHERE OWNER_TENANT = ? AND OWNER_NUMBER = ? UPDATE BULK_ITEM SET name = ? WHERE id = ? DELETE FROM BULK_CID_OWNER WHERE number = ? AND tenant = ? ``` So the two statements are now pinned in the opposite order, and the test is renamed `testUnrelatedPendingChangeIsFlushedByTrailingFlush`. What the assertion establishes is that the `UPDATE` comes *after* the candidate `SELECT` and therefore cannot come from a pre-flush — that distinction is the whole point of the test, so it has to stay ordered. What does not matter is where the bulk delete's own `DELETE`s fall around it; those are ordered inside the flush, and the assertion does not pin them. All four order assertions in the class now have that same shape: candidate `SELECT` first, then the write. Rebased on master, braces added as solomax asked, and the bulk and flush packages are 58/0/0 on Derby and on H2. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
