[Senior Devs] Amarok and SQL queries

[Soren Harward]

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 <olivier at churlaud.com>
wrote:

> Le 01/11/2015 18:15, Soren Harward a écrit :
> > On Sun, Nov 1, 2015 at 6:15 AM, Olivier Churlaud <olivier at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-- 

Soren Harward
stharward at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20151102/e1a107e8/attachment.html>