No support for setBinaryStream(int,IS,long)
Brought to you by:
ickzon
Hibernate 4.1.12 is using setBinaryStream(int,InputStream,long) insteat of setBinaryStream(int,InputStream,int) in order to specify the length of a blob. This does not work with jTDS, as it throws an AbstractMEthodError().
The JDBC4 method sould be implemented, eighter by forwarding to the old method of the size fits into an int, or by generally forwarding the long value, if this can be done easily.
Basically, the issue affects Clob as well. There is the same situation with :
public void setCharacterStream(int parameterIndex, Reader reader, long length) throws SQLException
public void setCharacterStream(int parameterIndex, Reader reader, int length) throws SQLException
Workaround : switch from jtds to microsoft's sqljdbc4
We also hit this problem (hibernate 4.2.7) when storing a Blob, which was calling setBinaryStream(int,InputStream,long).
I have created a patch for 1.3.1 which forwards the method calls on to the methods which accept the int length. I have reused the same error messages which are used by setBlob(int parameterIndex, Blob x) and setClob(int parameterIndex, Clob x) when the length of the data is > Integer.MAX_VALUE.
We have only checked that the change for setBinaryStream(int,InputStream,long) is working on our system, not the clob changes. I regret to say that I have not looked at the unit tests as at the moment they are complaining about a missing junit dependency.
See attached patch file binary_stream.patch
Is there a version of jtds available for downloading that has this patch applied? I don't see a version 1.3.2 anywhere.
I am not aware of any, but then I have not looked recently. It's easy enough to download the source and apply the patch and build. However that said we have since given up using the jTDS driver for new work and use the MS driver. Our reason is that newer versions of hibernate mandate JDBC >= 4.0 and the issue we found with the jTDS driver was that although it "Implements" the JDBC 4.0 interfaces so that it compiles, it does not actually implement some/all of the methods, but instead throws a AbstractMethodError, as in the case of this bug report.