Labels and uniqueid Was: some crash report by Rich

[Maximilian Kossick]

On Thursday, 9. November 2006 03:47, Alexandre Oliveira wrote:
> The crash is in:
>  for(QMap<QString, QStringList>::ConstIterator it = newLabels.begin();
> it != endLabels; ++it ) {
>         CollectionDB::instance()->setLabels( it.key(), it.data(),
> m_playlistItem->uniqueId(), CollectionDB::typeUser );
>     }
>
> m_playlistItem->uniqueId() is wrong there, as when tagdialog isn't
> called from playlist, m_playlistItem will be null. Also, it'll return
> current item, so if the user uses next or previous and change labels
> for different tracks, all of them would use the same uniqueid on that
> call.
>
> I could fix it by making newLabels use a QPair with the url and the id
> as key, or by storing the ids in other map, or even by refactoring
> CollectionDB::setLabels() so that it finds the id by itself, but all
> this brought me question:
> Isn't having urls and uniqueids on labels table redundant? We already
> have both on statistics, so when amarok finds out about url changes,
> it could update the url on migrateFile(), like it happens for lyrics
> table.
>
It is possible to have labels for a file without statistics, so we need the 
uniqueid column in tags_labels. Why do you think that the urls in tags_labels 
are redundant? Updating the url in migrateFile() is a good idea, i'll fix 
that asap.

Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061109/f136ffb6/attachment.sig>