failed SQL queries in the dynamic branch

[Andrew Turner]

Jeff,

I don't use it - this is just some upgrade code failing. The upgrade
that it's performing is converting the URL column from the type
VARCHAR(255) to VARBINARY(255) for MySQL (the 'upgrade' happens for
other DBs too, but it ends up still as a VARCHAR(255) ). This is
necessary as in MySQL, the VARCHAR type can only store a subset of
valid URLs - it cannot store control characters eg unicode 0x82.

This isn't a problem in any way, as long as you don't care whether the
playlists table exists as, as far as I can tell, it probably won't for
the average person running 1.4.1, even though you tried to create it
before 1.4.1 was released.

After the upgrade code has been run, the playlists table will
definitely exist, so it really doesn't matter.

Andrew

On 16/07/06, Jeff Mitchell <kde-dev at emailgoeshere.com> wrote:
> > As for the playlists table not existing - that is not a problem with
> > the branch. That table should exist in trunk as of Persistent Tables
> > Version 12, which is from the end of May. (revision 546372) . I would
>
> Andrew--
>
> What is the playlist table being used for?  I created the playlists table a
> bit back to start thinking about making playlists exist in the database as
> opposed to a directory of M3U files, but I haven't gotten around to that yet.
> Alexandre and I had recently discussed working on this porting as well as
> some other things related to playlists.
>
> What I'm getting at is that the schema for the playlists table was not
> necessarily set, which I didn't think was an issue since no one was actually
> using it.  Could you explain how it's being used, and whether changes to the
> schema are going to be an issue for you?
>
> Thanks,
> Jeff
>