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-automations opened this issue Jun 28, 2012 · 17 comments

Comments

@firebird-automations
Copy link

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-automations
Copy link
Author

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-automations
Copy link
Author

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-automations
Copy link
Author

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-automations
Copy link
Author

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-automations
Copy link
Author

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-automations
Copy link
Author

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-automations
Copy link
Author

firebird-automations 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 (archive)

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-automations
Copy link
Author

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-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.3 [ 10440 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

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

@firebird-automations
Copy link
Author

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-automations
Copy link
Author

Modified by: @mrotteveel

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

resolution: Won't Fix [ 2 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

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

resolution: Won't Fix [ 2 ] =>

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

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

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Link: This issue is replaced by JDBC446 [ JDBC446 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

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

resolution: Duplicate [ 3 ]

@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
Projects
None yet
Development

No branches or pull requests

2 participants