On 28-6-2012 13:22, the_a_rioch wrote:

>
>> By default Jaybird will make a connection with characterset NONE. If you
>> want to use a different characterset (and you usually want that!), you
>> need to explicitly specify it in the JDBC url (or if you use a
>> datasource: in the datasource properties).
>
> Hmmm, it sounds like it is not standard JDBC property ?

JDBC only specifies a very limited number of properties (for
datasources), other than that everything else is JDBC driver or
datasource implementation-specific

> If Java apps always run in some pre-defined flavour of unicode, if the database is created in some standard charset (here - UTF8), why cannot JayBird query database and choose best matching default.

The characterset has to be specified on connect. Also, the connection
characterset does not have to match the database characterset at all
(firebird server will translate between db charset and connection
charset; if possible).
Guessing for the user could result in 1) decreased performance because
it would need to connect twice or 2) incorrect behavior. You as the
developer / db administrator simply have to be explicit when defining
the connection.

>
> Yes, potentially different tables/columns MIGHT have different charsets, but that is marginally rare case and that is when one could override default by JDBC URL options.
>
> I would ask TS to implement that parameter, since they had some built-in language selection. But overall to me it looks a bit outdated approach.

Looking at the documentation at
http://www.trackstudio.com/connecting-firebird.html the developers of TS
don't need to do anything. You just need to include the charSet or
encoding property in the JDBC url specified in the
hibernate.connection.url property.

eg
hibernate.connection.url=jdbc\:firebirdsql\://localhost/c\:/trackstudio.gdb?encoding=UTF8

or if you are only working in Russian:
hibernate.connection.url=jdbc\:firebirdsql\://localhost/c\:/trackstudio.gdb?encoding=WIN1251

All JDBC drivers work similar to this. You can question the decision to
use characterset NONE as the default, but apart from UTF8 it is the only
sensible default. Besides, UTF-8 has the downside that it results in
significant protocol overhead which you usually don't need if you only
use your local language.

> It seems TS developers failed to do it right, and mere users would fail too.

>>> And there would be half-dozen things to subclass.
>>
>> Not sure why you would need to subclass half-dozen things. You would
>> only need to subclass the dialect.
>
> Mmm... i meant subclassing here like Windows Ui where u 'subclass' each windows.
> I meant like subclassing the Dialect contains (consists of) subclassing those datatypes one by one. And only one type would not be enough.

No it actually isn't that involved at all (AFAIK). You wouldn't need to
subclass datatypes.

> ...and then i wound need to compile it and replace it in the hibernate Jar probably. Frankly, i fear that surgery session :-)

You don't need to replace the Hibernate jar. Creating your own subclass
should be sufficient (though I seem to remember that it does need to be
in the original package).

> Thanks. Hope to hear from u next week.
> Hope it would be both useful for me and for u, if you would find something useful from that TS crash.

I am not 100% sure, but it might simply be related to putting a non-JRE
jar in the jre/lib folder. But I will investigate.

Mark
--
Mark Rotteveel