OceanBase Connector/J supports both MySQL mode and Oracle mode and is continuously compatible with the behaviors of MySQL JDBC and Oracle JDBC. Starting from V2.4.18, you can use the URL parameter obStrictJdbcCompatibility to enable strict compatibility (true) or non-strict compatibility (false, default). This topic describes the behavior differences between the two compatibility modes to help you understand the compatibility during business migration.
The obStrictJdbcCompatibility parameter takes effect starting from V2.4.18. If the strict compatibility mode is extended in later versions, the corresponding table rows or sections will be added to this topic. For more information, see the version release notes of the corresponding version.
Parameter description
Value |
Description |
|---|---|
false (default) |
Non-strict compatibility: keeps the existing behaviors of OceanBase Connector/J and ensures compatibility with applications of earlier versions. It does not require strict alignment with mysql-jdbc or ojdbc. |
true |
Strict compatibility: aligns with the behaviors of native MySQL JDBC or Oracle JDBC in the following aspects (see the table below for details). |
You can set this parameter in the JDBC URL. Example: ...?obStrictJdbcCompatibility=true.
Behavior comparison table (up to V2.4.18)
The following behaviors are described under the assumption that obStrictJdbcCompatibility takes effect for V2.4.18 and later versions.
Behavior |
Scenario |
Strict compatibility mode ( true) |
Non-strict compatibility mode ( false, default) |
|---|---|---|---|
| Batch execution | executeBatch / executeLargeBatch |
If the batch contains a SELECT statement, an exception is thrown, which is consistent with the behavior of MySQL JDBC and Oracle JDBC. | No restriction is imposed on the SQL types in the batch. You can execute the batch. |
| Update execution | executeUpdate / executeLargeUpdate + MySQL mode |
If the statement is a SELECT statement, an exception is thrown, which is consistent with the behavior of MySQL JDBC. | No restriction is imposed on the SQL types in the batch. You can execute the batch. |
| Update execution | executeUpdate / executeLargeUpdate + Oracle mode |
No restriction is imposed on the SQL types in the batch. You can execute the batch, which is consistent with the behavior of Oracle JDBC. | No restriction is imposed on the SQL types in the batch. You can execute the batch. |
| Scrollable result set | ResultSet type is TYPE_FORWARD_ONLY |
When you call the backward or absolute positioning methods such as previous() and beforeFirst(), an exception is thrown, which is consistent with the behavior of MySQL JDBC 8. |
No error is returned when you call the backward or absolute positioning methods (the existing behaviors of OceanBase JDBC are retained). |
Note
Strict compatibility aligns with the behaviors of native drivers on a per-behavior basis. It does not implicitly enable all MySQL or Oracle dialects or protocol options. Other URL parameters are still subject to their respective documentation.
Notice
If your application relies on the behaviors of earlier versions of Connector/J, such as allowing the use of the scrollable result set API in TYPE_FORWARD_ONLY mode or not validating SELECT statements in batch/update APIs, these behaviors are retained by default when you upgrade to V2.4.18 or later. The strict compatibility mode is only enabled when you explicitly set obStrictJdbcCompatibility=true.