Subject | Rejecting connection without explicit character set in Jaybird 3: Keep it or remove it. |
---|---|
Author | Mark Rotteveel |
Post date | 2017-01-06T10:06:52Z |
In Jaybird 3 I made a change to reject connections without explicit
character set, see also http://bit.ly/2iLa5jl
The reason for that is that 1) the original default of NONE is usually
not the right option, and changing the default could break existing
applications in subtle ways, and 2) the way NONE works is slightly
different in Jaybird 3: we now take explicit character sets of columns
into account with NONE, so this could also break in subtle ways. The
choice was between a sternly worded warning in the release notes (which
probably will be ignored), or to be very explicit and annoying by
rejecting the connection in the hope that people pay attention.
However this change is still pretty aggressive, so I'd like to know your
opinions: should I keep it, or remove it (and fallback to the warning I
introduced in Jaybird 2.2).
I also had one report - which I have not been able to reproduce so far -
that using system property
org.firebirdsql.jdbc.defaultConnectionEncoding sometimes doesn't work. I
haven't been able to get more information as the reporter left a comment
on an existing ticket instead of creating a new one, and I get a
delivery error on the registration email address in the tracker.
Mark
--
Mark Rotteveel
character set, see also http://bit.ly/2iLa5jl
The reason for that is that 1) the original default of NONE is usually
not the right option, and changing the default could break existing
applications in subtle ways, and 2) the way NONE works is slightly
different in Jaybird 3: we now take explicit character sets of columns
into account with NONE, so this could also break in subtle ways. The
choice was between a sternly worded warning in the release notes (which
probably will be ignored), or to be very explicit and annoying by
rejecting the connection in the hope that people pay attention.
However this change is still pretty aggressive, so I'd like to know your
opinions: should I keep it, or remove it (and fallback to the warning I
introduced in Jaybird 2.2).
I also had one report - which I have not been able to reproduce so far -
that using system property
org.firebirdsql.jdbc.defaultConnectionEncoding sometimes doesn't work. I
haven't been able to get more information as the reporter left a comment
on an existing ticket instead of creating a new one, and I get a
delivery error on the registration email address in the tracker.
Mark
--
Mark Rotteveel