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
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
