For Amarok 2.0, one of the issues which came up at the multimedia meeting, was the abstraction of database backends to a proper object oriented architecture. This also included the possibility of using plugins, or using the inbuilt Qt SQL classes. I’ve noticed that they support a wide range of databases, which would be handy.
When this discussion came up originally, some concerns were voiced about the efficiency and flexibility of the classes, but primarily for the 3.3 release – that they were inefficient and difficult to work with.
Since we need to optimise our database queries, because they can be quite database intensive, it would be interesting to know if anybody has had any sort of experience with these classes in the reworked Qt4. Is the convenience of generic Qt sql classes outweighed by the flexibility and robustness?
8 Comments
We’ve used the Qt4 db classes and I must say they work perfectly. I haven’t worked with the db classes in Qt3, but in 4 it is relatively easy….
Do I have wishes? Of course. Asynchronyous db stuff would be pretty cool, and of course support for more db’s. But in general I’m happy with it.
Even for the most simple db stuff we do with a simple sqlite db we use the Qt classes…
maybe strigi will be another option for Amarok? join #strigi on freenode & ask…
wow, good morning, you should join #kat and not #strigi as #strigi isn’t in use yet…
Why the need to use SQL? Why don’t you use gdbm or qdbm or tdb or bdb? Even if you use SQL, having multiple backends brings choice, but are really people using other than sqlite?
@Sebastián: Certainly! Using mysql or pgsql over sqlite brings speed improvements of many magnitudes – they are much faster!
One thing that is really cool in Qt4 is that with the modelview stuff you will be able to switch models (from a one db to another) if one database doesn’t cut it while your view code wont change.
P.S. your e-mail checker doesn’t allow which is a valid e-mail char
Stick to an embedded database and tuned sql. Sqlite is fast enough for what amarok needs, and doesn’t need a separate daemon to run it. Mysql and Pgsql are nice, and I can see how using that if you had a shared music repository would be nice, but the same could be done by sticking the sqlite db on that same share. sqlite has no problem with multiple processes accessing the same db. A database running on a desktop system (unless already used for something else) would be bloat.
In my experience, unless multiple database backends is the ultimate goal the database abstraction always has to cater to the lowest common denominator, which means you have all the usefulness of a full featured rdbms like postgresql, but have to limit yourself to what sqlite can do anyway, unless your db has approximated more advanced features in the bindings proper.
@Joseph: This is not true at all. A mysql or postgres daemon barely uses any resources on a regular desktop machine. I think it is a common misconception that using idle processing power/resources justifies calling it bloat. If it’s not doing anything, use it!
Regardless, catering for the lowest common denominator by no means that the advantages of expert dbs is compromised. The abstraction means each plugin could handle the requested data in a different way.