<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>