Subject | Re: [Firebird-Java] Re: Approaches at JB-to-FB conenctions regarding charsets |
---|---|
Author | Roman Rokytskyy |
Post date | 2012-07-03T13:45:42Z |
>> > To me it looks quite opposite.Any web application producing a garbage like the screen you published
>> > http://www.trackstudio.ru/forum/download/file.php?id=212
>> > Users would instantly detect and "cry early"
>>
>> Aha, and what about the applications that compute in background?
>
> And you start them without user interactions at all ?
would simply cause user to close the web browser, not to call the
support.
> And u change database/jaybird without shutting them down ?Firebird allows to change that on the fly. But I do not create
databases with NONE character set, so no need to worry about.
>> > In a way that users would see garbage, cease operations andI am not ready to introduce such change in 2.2.0.
>> request
>> > admin to fix it.
>>
>> Not an option, since things might get screwed before somebody
>> notices.
>
> In some very specific circumstances.
> And for the rest NONEers things might get screwed at any time due to
> environment change.
> One time chance to screw rather non-typical installments vs continuos
> chances to screw typical ones.
>
> That is "breaking changes in JB 2.2.0" not mere "release notes for
> 2.1.7"
>> No double conversion - neither piece of code will apply anyFBClient won't do this anyway - I know how it works. It will pass the
>> conversion
>> 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.
>
> So you rely on FBClient VERY UNLIKELY would transcode on it's own.
DPB in unchanged way to server and will pass byte array with string
contents to Jaybird. The lower-level part of Jaybird will process bytes
arrays and pass them to the upper levels. The upper level will construct
a string applying the environment's default encoding if NONE is used.
>> That is the requirement of Java, you have toThat's what we do - we use environment's default encoding.
>> live with it.
>
> You can workaround it.
> You can explicitly fail.Yes, that is possible. Not for 2.2.0, since that is too late.
> Or You can implicitly apply some heuristics.No heuristics - only simple rules.
> You rely on FBClient not trying to Query GetThreadLocale and startI guess all your confusion is caused because you're new to Java. When
> transcoding to ANSI or OEM.
> I rely upon Jaybird doing the same until explicitly .
you get some experience in Java, especially in web area, you will be
very carefull about string-to-byte conversion and back and will pay
attention to it.
>> Below that level only bytes are shifted over the wire.Yes. FBClient.dll shifts only bytes - it does not interpret them. The
> I was talking not about wire protocol, but about Jaybird working via
> FBClient.dll
buffer received from the server is passed without the modification to
the layer above. In our case that is Jaybird, which also has it's
low-level part that performs no conversions and does not use strings and
the JDBC API part where we have to convert the data accordingly. The
rules are straightforward - if no charset is specified, we have to use
the default one. That is the Java convention. That might be different
from your expectations, but it is how Java world looks like.
Roman