Database issues

[Jeff Mitchell]

Hey guys, I need some opinions/consensus.

Right now, various fields in the database (like paths) are 1024
characters in length. Since they're UTF-8 encoded, this gives us at
least 341 characters.

There are two problems with this, however.

The first is that indexes are being created which can't work on a field
above size 1000 (without custom recompilation). Hence you get some nasty
errors, plus some unique indexes that aren't actually created. (Whether
the indexes are actually needed is another matter.)

The more troubling issue is that for some reason, some people have
InnoDB being used as their backend, which may be from having a database
created before proper skipping of InnoDB was being used (perhaps the
proper skipping was introduced in 2.1 and these people have 2.0
databases). Although you can try to fix this by specifying the backend
at table creation time, you cannot just convert them for the people that
already have it. The issue is that InnoDB supports certain types of
fields only up to a length of 768 characters or so (at least 256 UTF-8
characters)...so the conversion process upgrading database version 4 to
5 fails and these people get weird and random output for their
tags/filenames.

Regardless of which solution we pick, we should put in code to specify
MyISAM at table creation time.

The *best* solution, from a purely technical standpoint, is to have
those users wipe their DB and try again. Not a great solution though in
terms of user satisfaction.

The next best solution is to reduce the length of those various columns
so that they fit in InnoDB -- but we don't know what other InnoDB issues
we might run into in the future.

The next best solution after that is ?????

Thoughts?

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20090709/74d8b807/attachment.sig