On 6/27/07, Trevor Talbot <[EMAIL PROTECTED]> wrote:
On 6/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > So the choices seem to be:
> > >
> > > (1) Databases that corrupt if you move across platforms.
> > > (2) A 10MB database engine
> > > (3) Leave things as they are
> OK. Here is a crazy idea for consideration:
>
> You know that you can create a custom collating function as a
> DLL or shared library and load it at runtime, right? This has
> been a capability since version 3.3.7. Suppose we define a
> special table in the database file that is designed to hold
> DLLs and/or shared libraries.
After thinking a bit, it occurs to me that there's a compromise for
the Unicode case that might be workable. The algorithm for collation
is pretty stable, it's just the locale data that's the problem. If
SQLite understands the algorithm, then locale data can go into special
tables in the database itself.
Applications manipulating the database schema would need to have the
relevant collation data on hand to fill in the database, but other
apps concerned with only the data could operate without any special
knowledge. This approach keeps the database internally
self-consistent while avoiding platform and versioning issues.
It's a thought.
I love your idea and seems the most promising by far.
If we could have it in a way such that people who only use a specific
set of locales (like applications that are only internationalized for
the german, spanish and italian market, for example) could only have
the locale data they need (like ignore hebrew or chinese), I believe
that would be the best of all worlds.
Maybe we could have a database (the one with the 10MB in size) in the
contrib area with all the locale data and people would then import the
locales they need into their own databases on creation.
Indexes would continue to be coherent across platforms and different
locales (with the proper care).
This is good even for embedded devices, as they are usually deployed
on a single locale, and can have only the locale data they need.
Best regards,
~Nuno Lucas
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
