Skip to content
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

Batch insert with setBinaryStream inserts an empty BLOB [JDBC312] #358

Closed
firebird-automations opened this issue May 22, 2013 · 10 comments
Closed

Comments

@firebird-automations
Copy link

Submitted by: A Drouard (adrouard)

Attachments:
TestBlobWriting.java

When using setBinaryStream(int, InputStream, int) with batch execution, the rows in the second batch (and the following) contain an empty BLOB.
The rows in the first batch get correctly inserted.
All rows get correctly inserted when not using batch execution.

Commits: 129f804 903f337 FirebirdSQL/fbt-repository@b9af7db FirebirdSQL/fbt-repository@0625014

@firebird-automations
Copy link
Author

Commented by: A Drouard (adrouard)

JUNIT test case TestBlobWriting.java
test1 : one batch of 10 inserts OK
test2 : insert with no batch OK
test3 : three batch of 10 inserts KO

@firebird-automations
Copy link
Author

Modified by: A Drouard (adrouard)

Attachment: TestBlobWriting.java [ 12320 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

In Jaybird 2.1.6 this didn't work at all: setting a blob in a batch resulted in a FBDriverNotCapableException (for both test1 and test2)

org.firebirdsql.jdbc.FBDriverNotCapableException: Not yet implemented.
at org.firebirdsql.jdbc.field.FBBlobField.getCachedObject(FBBlobField.java:168)
at org.firebirdsql.jdbc.AbstractPreparedStatement.addBatch(AbstractPreparedStatement.java:785)
at nl.lawinegevaar.fb.jdbc312.TestBlobWriting.insert(TestBlobWriting.java:158)
at nl.lawinegevaar.fb.jdbc312.TestBlobWriting.test1(TestBlobWriting.java:73)

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Thanks for the clear testcase, it made finding the cause relatively easy. There are two bugs involved.

The first problem is that a copy of the blob id of the last blob created in the previous batch execution stays behind in one of the internal structures. When adding parameters for the second and third batch this actually causes Jaybird to ignore the InputStream, and copy the last inserted blob from the server back to the client.

The second bug occurs when making that copy: Jaybird does not update a length variable (it is initially 0), so on execute of the batch it creates a new blob of 0 bytes.

If it weren't for the second bug Jaybird would actually have created copies from the last inserted blob of the previous batch execution, ignoring the data of the provided InputStream.

I will fix this for Jaybird 2.2.4 (and 2.3).

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Version: Jaybird 2.2.1 [ 10474 ]

Version: Jaybird 2.2 [ 10053 ]

Fix Version: Jaybird 2.2.4 [ 10531 ]

Fix Version: Jaybird 2.3 [ 10440 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Workaround: Call setNull(1, Types.BLOB) on the prepared statement (where 1 is the index of the parameter to set) before setting the inputstream, this will remove the blobid from the internal structure.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Fixed in Branch_2_2, trunk (2.3) to be done

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Also fixed in trunk

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment