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
Always treat (VAR)CHAR CHARACTER SET OCTETS as if it is actually (VAR)BINARY [JDBC240] #289
Comments
Modified by: @mrotteveelFix Version: Jaybird 2.3 [ 10440 ] |
Modified by: @mrotteveeldescription: Currently the driver has partial support for treating (VAR)CHAR CHARACTER SET OCTETS fields as (VAR)BINARY using the parameter octetsAsBytes (see JDBC87). 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. => Currently the driver has partial support for treating (VAR)CHAR CHARACTER SET OCTETS fields as (VAR)BINARY using the parameter octetsAsBytes (see JDBC87). 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. |
Modified by: @mrotteveel |
Modified by: @mrotteveelassignee: Roman Rokytskyy [ rrokytskyy ] => Mark Rotteveel [ avalanche1979 ] |
Commented by: Vjacheslav Borisov (slavb18) I think that FBResultSetMetaData.getColumnType should return Types.VARBINARY 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 |
Modified by: Vjacheslav Borisov (slavb18)Attachment: FBResultSetMetaData.java.patch [ 12522 ] |
Commented by: @mrotteveel 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. |
Commented by: Vjacheslav Borisov (slavb18) jaybird 2.2 will not contain this patch? |
Commented by: @mrotteveel 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 (JDBC408) to check and if possible include your patch for Jaybird 2.2.9. |
Commented by: @mrotteveel |
Modified by: @mrotteveelstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @mrotteveel
Is duplicated by JDBC205
Jira_subtask_outward JDBC408
Attachments:
FBResultSetMetaData.java.patch
Currently the driver has partial support for treating (VAR)CHAR CHARACTER SET OCTETS fields as (VAR)BINARY using the parameter octetsAsBytes (see JDBC87).
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.
Commits: b907680
The text was updated successfully, but these errors were encountered: