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

Investigate options for more intelligent decision of encoding for connection without explicit characterset [JDBC257] #304

Closed
firebird-issue-importer opened this issue Jun 28, 2012 · 17 comments

Comments

@firebird-issue-importer

Submitted by: @mrotteveel

Is replaced by JDBC446

Currently Jaybird will always use the default system encoding of Java for converting between strings and bytes when no connection characterset or NONE is used for connecting to Firebird.

It may be a good idea to change this to first try to use the characterset of the database itself. If that is NONE as well, then fallback to the default system encoding. The connection characterset would remain NONE, but the encoding used in FBStringField would change to match the database - if possible.

Although this sounds good in theory, it will need to be tested to ensure it works OK and does not cause compatibility problems, and if it is easy to efficiently retrieve the database characterset.

Commits: b8ddc6e

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 28, 2012

Modified by: @mrotteveel

description: Currently Jaybird will always use the default system encoding of Java for converting between strings and bytes when no connection characterset or NONE is used for connecting to Firebird.

It may be a good idea to change this to first try to use the characterset of the database itself. If that is NONE as well, then fallback to the default system encoding. The connection characterset would remain NONE, but the encoding used in FBStringField would change to match the database - if possible.

Although this sounds good in theory, it will need to be test to ensure it works OK and does not cause compatibility problems.

=>

Currently Jaybird will always use the default system encoding of Java for converting between strings and bytes when no connection characterset or NONE is used for connecting to Firebird.

It may be a good idea to change this to first try to use the characterset of the database itself. If that is NONE as well, then fallback to the default system encoding. The connection characterset would remain NONE, but the encoding used in FBStringField would change to match the database - if possible.

Although this sounds good in theory, it will need to be tested to ensure it works OK and does not cause compatibility problems, and if it is easy to efficiently retrieve the database characterset.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 29, 2012

Commented by: @mrotteveel

Roman suggests that if the connection characterset is NONE and the database characterset is NONE as well, that we terminate the connection.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 29, 2012

Commented by: Roman Rokytskyy (rrokytskyy)

No, I suggest to drop the connection if database charset is NONE and connection charset is not specified. This is the "FB beginners case". If encoding property is set explicitly to NONE, we have to assume that people know what they are doing, especially when charSet=XXX, which means "I know how to interpret those data".

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 29, 2012

Commented by: @mrotteveel

To be honest, I don't see a real use case for specifying NONE explicitly, so that is why I equated the no explicit connection characterset as being identical to NONE.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 29, 2012

Commented by: Roman Rokytskyy (rrokytskyy)

Backward compatibility only - you don't really want to know how people can misuse the NONE charset. That is why we have the encoding and charSet properties in Jaybird - to let people somehow solve the issues with the legacy databases they have.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 29, 2012

Modified by: @mrotteveel

summary: Investigate options for more intelligent decision of encoding for connection characterset NONE => Investigate options for more intelligent decision of encoding for connection without explicit characterset

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 29, 2012

Commented by: @mrotteveel

Changing the existing behavior could actually lead to logical data corruption, see my post http://tech.groups.yahoo.com/group/Firebird-Java/message/10657

If we want to change anything, we might actually have no other option than to refuse connections without explicitly setting charSet or encoding or we need to put really big warning signs in the release notes, add an SQLWarning to the connection and write warnings to System.err and the log ;)

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 7, 2012

Commented by: @mrotteveel

As a first step I added code (for Jaybird 2.2) to log a warning and add a warning on the connection.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 14, 2012

Modified by: @mrotteveel

Fix Version: Jaybird 2.3 [ 10440 ]

@firebird-issue-importer
Copy link
Author

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

Modified by: @mrotteveel

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

@firebird-issue-importer
Copy link
Author

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

Commented by: @mrotteveel

I decided not to change anything other than keeping the warning introduced in Jaybird 2.2. Changing to default to UTF-8 has its obvious downside with regard to logical corruption, and refusing connection if no character set is specified will be very inconvenient. We are simply between a rock and a hard place on this.

@firebird-issue-importer
Copy link
Author

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

Modified by: @mrotteveel

status: Open [ 1 ] => Closed [ 6 ]

resolution: Won't Fix [ 2 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 30, 2016

Modified by: @mrotteveel

status: Closed [ 6 ] => Reopened [ 4 ]

resolution: Won't Fix [ 2 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 30, 2016

Commented by: @mrotteveel

Reversed my previous decision: we will now reject the connection if no explicit character set was specified. See also JDBC446

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 30, 2016

Modified by: @mrotteveel

Link: This issue is replaced by JDBC446 [ JDBC446 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 30, 2016

Modified by: @mrotteveel

status: Reopened [ 4 ] => Resolved [ 5 ]

resolution: Duplicate [ 3 ]

@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