On Mon, 2013-06-24 at 11:30 +0200, Lionel Elie Mamane wrote:
> Wrt to section 3.2 Compilation:
>
> In indices on text-based columns (CHAR/VARCHAR), Firebird uses ICU to
> get binary-comparable sequences (collations). These collations may be
> different in different ICU versions.
Fun :-)
> This seems like a recipe for disaster to me. Our
> downstream distributors *will*, it at all possible, force system
> firebird and system ICU (e.g. Debian has a very strong policy on that
Sure sure - all sorts of distros will force that 'optimisation'
regardless of the consequences and without understanding the issue, and
we collectively will get to hold the can & field the horrible user
complaints :-)
> When opening an embedded-firebird .odb file, detect whether the
> indices are built with an incompatible / other ICU version, and then
> just automatically (silently?) rebuild them. I hope we can detect the
> situation automatically.
I love that solution. Sure we take a performance hit left & right &
center, but - we save hassle for everyone in the long run I think. I
guess it's a matter of using unicode/uversion.h's slightly odd binary
version foo.
I imagine we have a similar issue around the 2.5 -> 3.0 version upgrade
where we will want to prompt the user (?) presumably not silently -
upgrade the database format, or mark it read-only. Of course, prompting
the user is some last-refuge of desperation, but - at least having some
strong versioning in the .odb from day one, such that we can at least
warn users with old software: "this database is incompatible and was
written by a newer version, please upgrade" or whatever would be rather
nice.
HTH,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
--
To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1372070010.1526.282.ca...@linux-d2lh.site
