|Subject||Re: [Firebird-Java] Re: Approaches at JB-to-FB conenctions regarding charsets|
> Are there some statistics, how long takes establishing a connectionEstablishing connection is a sub-second op. But can you guarantee that
> and hence what would be the penalty for two-phase mode ?
the database charset is not changed between connections? Unlikely - yes.
Sure - no. But in the database world we have either TRUE or FALSE, not
> a. wire protocol is extended to query/specify charset afterEasier is to ensure that no new database has NONE and let those, who
> connection is made
> b. if client connects without specifying charset, then connection is
> c. in restricted mode client can
> c.1: specify choosen connection, switching connection to full mode
> c.2: ask server which charset it considers broad enough (least common
> c.3: read metadata, if client wants to choose a charset w/o server
> hints (say, want to reduce network load and choose some SBCS): only
> RDB$... tables and views, only 7-bit ASCII strings and numbers, only
> read, no side-effects - no UFDs nor SPs,
> This would need both client and server orchestrated update.
> This would add single extra after-connect roundtrip, negotiating a
> charset, which is comparable to your proposal of covertly converting
> to DB default charset (which still would be needed to query)
use NONE do their dirty work further.
>> If we would default to connect with UTF-8 either you get all kindsYes.
>> transliteration errors or data is now stored in two different
>> in other words you introduce logical data corruption.
> Yes, transliteration errors like
> User would see it, panic and call HelpDesk instead of working noe the
> less - so, no data corruption. Until admins would mend the connection
> mode (even at least ugly and dirty fixing ?encoding=NONE) db would
> be usable for humans,so they would not enter new data.
>> The problem is that when the database charset and local systemAha, and what about the applications that compute in background?
>> are different when using NONE, in most cases you won't be able to
>> the logical data corruption that will occur when Jaybird changes its
>> behavior, so Jaybird will have no way to fail early.
> To me it looks quite opposite.
> Users would instantly detect and "cry early"
>> > P4: deny connections without explicitly specified charset. If NONEExcept that there is no such thing "NO conversion" in Java, it will use
>> is specified explicitly - do NO conversion at all, as told in FB docs.
> no critical comments from you
> Except for absolutely screwed sorting and partially text searchdepends on your connection encoding.
> I wonder if i would send then explicit statement like "EXECUTE BLOCK"
> with russian text constants inside, what would be...
> If i would create new table then (software version updating andIt will inherit on the fly, since you did not specify charset for the
> adjusting schema), would it inherit WIN1252 of database or WIN1251 of
> de-facto connection mode or NONE of de jure connection mode...
column. Has nothing to do with the client (fbclient.dll, Jaybird or
> In a way that users would see garbage, cease operations and requestNot an option, since things might get screwed before somebody notices.
> admin to fix it.
> Now, i think that clients are expected to behave similar to eachNo double conversion - neither piece of code will apply any conversion
> other, since they are all official.
> So let's imagine your proposal was ported to .NetProvider and
> Now imagine someone configured Jaybuird to use fbclient/fbembed.
> He does not specify connection charset, so fbclient/fbembed does
> covert transcoding while pretending they use NONE, then Jaybird
> seconds and makes yet another transcoding while pretending to use
> "Thames, ^W
> "Double conversion, sire!"
if NONE is used (explicitly or implicitly). The conversion to string
with platform's default encoding will happen far above the code that
performs network calls. That is the requirement of Java, you have to
live with it. Below that level only bytes are shifted over the wire.