Issue Details (XML | Word | Printable)

Key: JDBC-240
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Mark Rotteveel
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

Always treat (VAR)CHAR CHARACTER SET OCTETS as if it is actually (VAR)BINARY

Created: 04/Mar/12 10:22 AM   Updated: 07/May/17 12:32 PM
Component/s: JDBC driver, JNI/JNA layer, Wire protocol
Affects Version/s: None
Fix Version/s: Jaybird 3.0.0

File Attachments: 1. Text File FBResultSetMetaData.java.patch (1 kB)

Issue Links:
Duplicate
 

Sub-Tasks  All   Open   

 Description  « Hide
Currently the driver has partial support for treating (VAR)CHAR CHARACTER SET OCTETS fields as (VAR)BINARY using the parameter octetsAsBytes (see JDBC-87).

Change this to treat it always as being java.sql.Type.BINARY cq VARBINARY and make sure these changes are propagated everywhere in the driver (metadata, wire protocol, native implementation etc), as currently the octetsAsBytes property isn't used in all places.

Als consider this for SUBTYPE 1 blobs.

Rationale: Fields with CHARACTER SET OCTETS have a different handling in the wire protocol (eg in a UTF8 connection, the sqllen is still the number of characters(bytes), not 4 * the number of characters like other fields), treating it as a distinctly different type makes it easier to correctly handle this; it will also improve (correct) handling in tools that inspect metadata to decide on how to treat a field.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vjacheslav Borisov added a comment - 23/May/14 08:54 AM
I think that FBResultSetMetaData.getColumnType should return Types.VARBINARY
in case of octetsAsBytes and sqlsubtype == 1

In this case byte[] result will be corretctly converted to byte[] in eclipselink JPA, as it currently it tryes to convert byte[] to String becouse of Types.VARCHAR

Mark Rotteveel added a comment - 23/May/14 08:57 AM
As discussed by e-mail, I will consider applying this patch to Jaybird 2.2.6; Jaybird 3.0 should address this more thoroughly, but this looks like a quick win.

Vjacheslav Borisov added a comment - 30/Sep/15 05:14 AM
jaybird 2.2 will not contain this patch?

Mark Rotteveel added a comment - 30/Sep/15 07:38 AM
I lost sight of the patch as it was linked to the ticket for the (larger) changes for Jaybird 3.0. I have created a task (JDBC-408) to check and if possible include your patch for Jaybird 2.2.9.