Does using Qt as a SQL abstraction layer make sense? Absolutely. But is it the best option? Maybe. It'll depend on the stability of the layer and performance through it.
The current architecture made sense in 2007–8, but that was a long time ago. And the only way to find out if the decisions that were made then are still valid today is to create a git branch, port the code over to QtSQL, and see if it's worth making the change permanent. On Sun, Nov 1, 2015 at 12:20 PM Olivier Churlaud <oliv...@churlaud.com> wrote: > Le 01/11/2015 18:15, Soren Harward a écrit : > > On Sun, Nov 1, 2015 at 6:15 AM, Olivier Churlaud <oliv...@churlaud.com> > wrote: > >> I wonder: why are the mysql libraries directly used and not the Qt > framework > >> (QSqlQueries and so on)? > > IIRC, it's entirely historical. For a handful of reasons that were > > valid in 2008 but aren't any longer, the decision was made late (and > > kind of hastily, IMO) in the 2.0-beta cycle to switch from SQLite to > > MySQL Embedded. At the time, SQL performance through the Qt libraries > > was pretty lousy and unstable, and I don't think Qt supported MySQL > > Embedded at the time. At any rate, relying on a SQL database for > > Amarok 2's library has always been a non-ideal solution, but the only > > one that's actually worked. There were several failed attempts at a > > Nepomuk back end. Now, it would be nice to have Amarok work > > seamlessly with Baloo, because that would eliminate the collection > > scanner, which has always been the the source of Amarok's biggest > > problems in terms of database performance. But Baloo's emphasis on > > light weight (with good reason) means that Amarok is always going to > > need some kind of database to store all its internal information. > > > Thank you for this informations. > Do you think it would make sense to move to a Qt-based database > management? I find the code rather complex to interact with the > database, with different way of handling everything based on the > solution chosen by the user. In my opinion, working with the Qt solution > would reduce the complexity and simplify the maintainability. However, I > may (and I'm pretty sure of it) miss some of the constraints that may > force us to stay this way. > > Cheers, > Olivier > _______________________________________________ > Amarok-devel mailing list > Amarok-devel@kde.org > https://mail.kde.org/mailman/listinfo/amarok-devel > -- Soren Harward stharw...@gmail.com
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
