Investigate options for more intelligent decision of encoding for connection without explicit characterset [JDBC257] #304
Comments
Modified by: @mrotteveeldescription: 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. |
|
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. |
|
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". |
|
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. |
|
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. |
Modified by: @mrotteveelsummary: 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 |
|
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 ;) |
|
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. |
Modified by: @mrotteveelFix Version: Jaybird 2.3 [ 10440 ] |
Modified by: @mrotteveelassignee: Roman Rokytskyy [ rrokytskyy ] => Mark Rotteveel [ avalanche1979 ] |
|
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. |
|
Commented by: @mrotteveel Reversed my previous decision: we will now reject the connection if no explicit character set was specified. See also JDBC446 |
Modified by: @mrotteveel |
Modified by: @mrotteveelstatus: Resolved [ 5 ] => Closed [ 6 ] |
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
The text was updated successfully, but these errors were encountered: