GSoC application review - reimplementing personal metadata importers

[Konrad Zemek]

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