[prev in list] [next in list] [prev in thread] [next in thread]
List: amarok-devel
Subject: Re: [Senior Devs] Amarok and SQL queries
From: Soren Harward <stharward () gmail ! com>
Date: 2015-11-02 16:19:23
Message-ID: CANQojO6BBBVRnkVHPH=pk8prB9-YQnO8YQsbAJ1HXBBov7f37A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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
stharward@gmail.com
[Attachment #5 (text/html)]
<div dir="ltr">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.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 1, 2015 \
at 12:20 PM Olivier Churlaud <<a \
href="mailto:olivier@churlaud.com">olivier@churlaud.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Le 01/11/2015 18:15, Soren Harward \
a écrit :<br> > On Sun, Nov 1, 2015 at 6:15 AM, Olivier Churlaud <<a \
href="mailto:olivier@churlaud.com" target="_blank">olivier@churlaud.com</a>> \
wrote:<br> >> I wonder: why are the mysql libraries directly used and not the \
Qt framework<br> >> (QSqlQueries and so on)?<br>
> IIRC, it's entirely historical. For a handful of reasons that were<br>
> valid in 2008 but aren't any longer, the decision was made late (and<br>
> kind of hastily, IMO) in the 2.0-beta cycle to switch from SQLite to<br>
> MySQL Embedded. At the time, SQL performance through the Qt libraries<br>
> was pretty lousy and unstable, and I don't think Qt supported MySQL<br>
> Embedded at the time. At any rate, relying on a SQL database for<br>
> Amarok 2's library has always been a non-ideal solution, but the only<br>
> one that's actually worked. There were several failed attempts at a<br>
> Nepomuk back end. Now, it would be nice to have Amarok work<br>
> seamlessly with Baloo, because that would eliminate the collection<br>
> scanner, which has always been the the source of Amarok's biggest<br>
> problems in terms of database performance. But Baloo's emphasis on<br>
> light weight (with good reason) means that Amarok is always going to<br>
> need some kind of database to store all its internal information.<br>
><br>
Thank you for this informations.<br>
Do you think it would make sense to move to a Qt-based database<br>
management? I find the code rather complex to interact with the<br>
database, with different way of handling everything based on the<br>
solution chosen by the user. In my opinion, working with the Qt solution<br>
would reduce the complexity and simplify the maintainability. However, I<br>
may (and I'm pretty sure of it) miss some of the constraints that may<br>
force us to stay this way.<br>
<br>
Cheers,<br>
Olivier<br>
_______________________________________________<br>
Amarok-devel mailing list<br>
<a href="mailto:Amarok-devel@kde.org" target="_blank">Amarok-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok-devel" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br> \
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">Soren \
Harward<br> <a href="mailto:stharward@gmail.com">stharward@gmail.com</a></p>
</div>
[Attachment #6 (text/plain)]
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic