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

Always treat (VAR)CHAR CHARACTER SET OCTETS as if it is actually (VAR)BINARY [JDBC240] #289

Closed
firebird-automations opened this issue Mar 4, 2012 · 12 comments

Comments

@firebird-automations
Copy link

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

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.3 [ 10440 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

description: 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.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Link: This issue is duplicated by JDBC205 [ JDBC205 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

assignee: Roman Rokytskyy [ rrokytskyy ] => Mark Rotteveel [ avalanche1979 ]

@firebird-automations
Copy link
Author

Commented by: Vjacheslav Borisov (slavb18)

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

@firebird-automations
Copy link
Author

Modified by: Vjacheslav Borisov (slavb18)

Attachment: FBResultSetMetaData.java.patch [ 12522 ]

@firebird-automations
Copy link
Author

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.

@firebird-automations
Copy link
Author

Commented by: Vjacheslav Borisov (slavb18)

jaybird 2.2 will not contain this patch?

@firebird-automations
Copy link
Author

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.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Commits:
31d6db7
b907680

@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