New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support for large update counts (JDBC 4.2) #935
Conversation
Codecov Report
@@ Coverage Diff @@
## master #935 +/- ##
============================================
+ Coverage 68.67% 68.68% +<.01%
- Complexity 3891 3902 +11
============================================
Files 179 179
Lines 16391 16415 +24
Branches 2669 2673 +4
============================================
+ Hits 11256 11274 +18
- Misses 3887 3891 +4
- Partials 1248 1250 +2 |
03821c4
to
997fd9a
Compare
ebbdbcf
to
d34b4a7
Compare
601d48f
to
2e6cdc4
Compare
This feature is ready for 42.2.0, comments are welcome. |
Help me out to understand why you think this would be 42.2.0 ? Is this a new feature ? To me this seems to just be fixing a potential bug ? |
I agree with @jorsol version analysis |
Yes, is a new feature, in fact is a feature that must be implemented for JDBC 4.2.
In this case, it's hard that this break any existing APIs and for new features, it make sense to put in a minor release in a backwards-compatible manner, since this is not a patch or bug-fix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code and tests looks good to me except a couple of comments.
return uncompressUpdateCount(); | ||
public long[] getLargeUpdateCount() { | ||
long[] copyCount = uncompressLongUpdateCount(); | ||
return Arrays.copyOf(copyCount, copyCount.length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is copy required here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not really required, I guess there are no side effects of exposing the original array, so I will change that part.
|
||
//#if mvn.project.property.postgresql.jdbc.spec >= "JDBC4.2" | ||
@Override | ||
public long executeLargeUpdate() throws SQLException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you please co-locate this method with int executeUpdate
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
Assert.fail("A result was returned when none was expected. Returned: " + count); | ||
} catch (SQLException e) { | ||
// TOO_MANY_RESULTS("0100E"), is this the correct SQLState? | ||
Assert.assertEquals("0100E", e.getSQLState()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's better use org.postgresql.util.PSQLState
enum values, however I TOO_MANY_RESULTS
sounds strange for that case indeed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to use the PSQLState.
My question was because I have not found anywere this status code, it's not part of PostgreSQL error codes, and belongs to the Class 01- Warning group, so I guess is made up just for the driver use but is just strange, this is how the driver handle it since long time so I don't touch that part.
5291eaa
to
f416fea
Compare
Rebased and ready for review. |
92d3c8a
to
8034703
Compare
Should this be included in 42.2.1? |
This sounds like 42.3.0 |
Ok, fair enough. |
8034703
to
dcb7aac
Compare
@jorsol , would you please rebase on top of master? |
Sure, give me a day or two 🙂 |
dcb7aac
to
d32ffc1
Compare
Rebased. |
d32ffc1
to
5963221
Compare
Seems reasonable. We should aim at pushing this after resolving the conflicts. |
Added support for large update counts of the JDBC 4.2 API (Java 8+) This implementation supports: PreparedStatement.executeLargeUpdate() Statement.executeLargeUpdate(String sql) Statement.getLargeUpdateCount() Statement.executeLargeBatch() Statement.executeLargeUpdate(String sql, int autoGeneratedKeys) * Statement.executeLargeUpdate(String sql, int[] columnIndexes) * Statement.executeLargeUpdate(String sql, String[] columnNames) *
5963221
to
cc524b9
Compare
✅ Build pgjdbc 1.0.465 completed (commit 9161b21b1a by @jorsol) |
@jorsol is this ready to go ? |
Yes, this should be ready. |
PostgreSQL do support sending large counts for statements, and Java 8 have new methods that are not implemented in the driver.
This is an implementation for large counts and implement some methods like:
Most methods are copies of the non-Large versions, so they should behave equals with just the difference of returning long instead int.