faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: why postgres?
by muesli on Thursday 24/Feb/2005, @07:34
|
hey scott!
we (amarok) have dealed with quite all sqlite issues you could imagine ;-)
so, let me assure you, that i still believe it could be used, but some simple things have to be done:
a) you can set a threadsafe variable in the Makefile. this will help improve the situation!
b) why not use a singleton interface for searching? this way you can take care of the locking easily. if you need code: look at collectiondb.cpp/.h in amarok/src. there is even a connection pool n everything. that is also useful for other db interfaces, even though i dunno what qsql offers wrt this issue.
c) most sqlite issues can be easily solved by setting proper indices. when you do that, sqlite is barely slower than mysql. although, one must admit that there are more situations where sqlite is not able to use an index at all.
anyways, mysql or postgresql is to have imho. reconsider sqlite! it's worth the little hassle.
regards,
muesli |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: why postgres?
by muesli on Thursday 24/Feb/2005, @07:36
|
"anyways, mysql or postgresql is to heavy imho. reconsider sqlite! it's worth the little hassle."
s/have/heavy ;-)
...muesli
|
[
Reply To This | View ]
|
Re: why postgres?
by Scott Wheeler on Thursday 24/Feb/2005, @08:06
|
> we (amarok) have dealed with quite all sqlite issues you could imagine
Honestly I doubt it. amaroK is a very simple application (in database terms) relative to what we're working on. A music player with a couple MB of data is a very different beast trying to store and query graphs in a database that may easily grow to a few hundred MB.
> why not use a singleton interface for searching?
Because that's only useful for one process.
> most sqlite issues can be easily solved by setting proper indices
Not for heavy use of cross table selects on interrelated values. I literally had several queries that took 15 minutes on SQLite that were done in less than 1-2 seconds on PGSQL or MySQL. And that was just on a 10 MB test database. I'm not saying that the limitations of SQLite couldn't possibly be worked around, I'm just saying that there's no compelling reason to work around them when there are better databases available that already solve these problems.
SQLite also locks the entire database on write, which just isn't acceptable in a tool used frequently by multiple processes.
Basically, as Aaron already said -- it might be possible to work around all of the issues with SQLite. But in the end we'd just be implementing the features that other databases already provide and we'd need a daemon process anyway to handle communication with it, which, well, makes no sense.
|
[
Reply To This | View ]
|
Re: why postgres?
by Carlo on Thursday 24/Feb/2005, @11:46
|
I'd rather like to see Amarok integrate in such a new framework, instead that every application has it's own db. E.g. to access covers and the correspoding metadata with Digikam, without having to add a new album in digikam and the metadata stored twice.
If it would be possible to specify something like "apply <filter> on amarok:covers which are smaller than (x,y), jpegs and greenish, pipe result to <dialogX>,[...]", without having joe user to think about what the hell he is doing... ;)
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
