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-issue-importer opened this issue Mar 4, 2012 · 12 comments

Comments

@firebird-issue-importer
Copy link

@firebird-issue-importer firebird-issue-importer commented Mar 4, 2012

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 4, 2012

Modified by: @mrotteveel

Fix Version: Jaybird 2.3 [ 10440 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 4, 2012

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Aug 5, 2012

Modified by: @mrotteveel

Link: This issue is duplicated by JDBC205 [ JDBC205 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 23, 2014

Modified by: @mrotteveel

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 23, 2014

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 23, 2014

Modified by: Vjacheslav Borisov (slavb18)

Attachment: FBResultSetMetaData.java.patch [ 12522 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 23, 2014

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 30, 2015

Commented by: Vjacheslav Borisov (slavb18)

jaybird 2.2 will not contain this patch?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 30, 2015

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 3, 2016

Commented by: @mrotteveel

Commits:
31d6db7
b907680

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 3, 2016

Modified by: @mrotteveel

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

resolution: Fixed [ 1 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 7, 2017

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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants