On 30.04.2013 23:12, Matěj Laitl wrote:
On 30. 4. 2013 Konrad Zemek wrote:
Amarok 2.x importer should support importing data from both a full mysql
server and mysql-embedded file. To ensure that metadata from current
version of Amarok can always be synchronized, Collections::SqlCollection
class will be used
I don't think this is a good idea at all. It is like using a cannon to smash a
fly, and it would add great deal of complexity and open a can of worms.
I find this a bit puzzling. Ideally it would be made that importing from
Amarok 2.x Just Works (tm), without introducing additional logic and
instead reusing what's already implemented. Some changes to
SqlCollection might be in order (e.g. we wouldn't want a migration
dialog for imported database), and it may even be broken up in two
layers - the basics (the layer used by importers) and the rest (the
layer used for "normal collection). Of course, SqlCollection has some
more complicated logic inside, like using a buffer, but from the
perspective of Provider it would just be a convenient interface for
MySqlStorage / MySqlEmbeddedStorage. So from my viewpoint it's both
conceptually clearer and more maintainable.
That being said, I have much (much) less experience with Amarok than you
do, so I probably am just not seeing something here. If you would kindly
supply me with any major-ish point speaking against using SqlCollection,
I would gladly go along with just using MySqlStorage / MySqlEmbeddedStorage.
As an optional goal, backwards compatibility for Amarok 2.x
importer will be provided down to version 2.5. A version auto-detection
based on database schema would be added for convenience, with user being
able to specify the version explicitly.
No, I don't think you should be that elaborate. I think that the core schema
won't really change (and haven't changed since 2.5 or earlier) so perhaps only
thing to ensure compatibility with other versions is to fail gracefully when a
SQL query fails (and perhaps do some testing). User certainly doesn't want to
set some kind of version, it should just work. ;)
Obviously you're right about user setting version explicitly. Backwards
compatibility is two a bit different stories depending on how
current-version importing is implemented, so before refining this point
I'd love to get some more information about the SqlCollection issue.
Matěj
Konrad
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
