GSoC application review - reimplementing personal metadata importers

[Konrad Zemek]

On 01.05.2013 00:42, Matěj Laitl wrote:
> My bet that support code for actually using SqlCollection would be much
> heavier than implementing the A 2.x importer without it.
>
> Technical reasons not to use SqlCollection:
>   1. you'll be instantiating the beast just to use 2% of its functionality.
> SqlCollection is huge, including SqlRegistry, gui classes that are
> unconditionally instantiated, playlist support, you don't need albums that
> read their images from disc, etc. etc.
>   2. SqlCollection has much more assumptions on the environment than you'd
> need. For example it needs MountPointManager instantiated connected to the
> right database etc.
>   3. By using SqlCollection, you actually make it harder for you to support
> syncing against older/future Amarok versions because various (unrelated)
> methods assume the latest database schema.
>   4. In future, some users may not enable/build SqlCollection in favour of
> let's say NepomukCollection. But they still should be able to sync against it.

Thank you; these all are very good points. Now I can definitely see what 
you meant. So my two bullet points, refined into one, would now read:

  * Amarok 2.x importer should support importing data from both a full
    mysql server and mysql-embedded file. To make reading from both
    sources simpler, existing MySqlStorage and MySqlEmbeddedStorage
    classes will be used. The importer's code should be as decoupled
    from the database schema as possible, allowing it to support a range
    of previous and future versions of Amarok.


This much detail should suffice. I can see now that I misunderstood your 
previous comments about backward compatibility. You were of course 
right; as long as the core schema is not changed in some non-trivial 
way, there should be no problem with syncing with both older and newer 
versions.

> While you'll be able to make changes to SqlCollection to get rid of some of
> the limitations, please be prepared that I'll be against any changes to
> SqlCollection that make it more complicated (with regards to its primary
> purpose; cleanups are still welcome).

To be fair, I didn't mean complicating the class further, rather the 
contrary. :) But I can see now it would be a heavy job with little payout.

     Konrad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20130501/04f29682/attachment.html>