Oracle seems to have changed their error handling.
They now (tested with Oracle 18) behave more like other databases,
so we should validate whether one of the described error situations got
catched.
diff --git a/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/batch/exception/TestBatchLimitException.java b/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/batch/exception/TestBatchLimitException.java
index 26a2358..b129ac3 100644
--- a/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/batch/exception/TestBatchLimitException.java
+++ b/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/batch/exception/TestBatchLimitException.java
@@ -355,6 +355,9 @@
assertNotNull("Failed object was null.", failedObject);
if (!isOracle && !isPostgres) {
assertEquals(expectedFailedObject, failedObject);
+ } else if (isOracle) {
+ // since Oracle 18 we see a different behaviour, so test both ways
+ assertTrue(failedObject.equals(expectedFailedObject) || failedObject.equals(expectedFailedObjectOracle) );
} else {
// special case, as Oracle returns all statements in the batch
assertEquals(expectedFailedObjectOracle, failedObject);
@@ -370,6 +373,9 @@
if (!isOracle && !isPostgres) {
assertTrue("Did not see expected text in message. Expected <" + expectedFailureMsg + "> but was " +
msg, msg.contains(expectedFailureMsg));
+ } else if (isOracle) {
+ // since Oracle 18 we see a different behaviour, so test both ways
+ assertTrue(msg.contains(expectedFailureMsg) || msg.contains(expectedFailureMsgOracle));
} else {
// special case, as Oracle returns all statements in the batch
assertTrue("Did not see expected text in message. Expected <" + expectedFailureMsgOracle + "> but was " +
