The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: why postgres?
by Haden on Wednesday 23/Feb/2005, @08:41
|
I'm surprised too, sqlite is very small and is in public domain license.
|
[
Reply To This | View ]
|
Re: why postgres?
by Scott Wheeler on Wednesday 23/Feb/2005, @09:13
|
Well, Postgres is the third database that I've tried. I did the original mockup prior to the KDE conference this summer with SQLite and the performance for the type of queries that we're doing was so bad that it simply isn't an option. Also SQLite is really only designed to be used from a single process, so we'd have to implement locking and multi-user access in a daemon on top of it, which, well, at that point you're just implementing a database server, really, but without the performance of more robust databases.
So I then ported that mockup to MySQL, which performs fine, but is GPL'ed rather than LGPL'ed. As performance is similar for MySQL and Postgres, but Postgres has more flexible licensing (i.e. suitable for use in things linked to kdelibs) Postgres wins there.
WinFS is something completely different. It's what's called an Attribute Value System or object database -- and it's only being used for "My Documents", not the complete FS. What we're working on isn't something that's going to replace parts of the FS, it will supplement it with contextual information.
|
[
Reply To This | View ]
|
Re: why postgres?
by Marco Menardi on Wednesday 23/Feb/2005, @13:39
|
Have you ever tried FirebordSQL? It's a true database server, ACID compliant, multiplatform, license is a modified versions of the Mozilla Public License (so unfortunatly no pure GPL), takes relly few resources and is developed by an active community:
http://www.firebirdsql.org/
"Firebird is a relational database offering many ANSI SQL-99 features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers"
|
[
Reply To This | View ]
|
Re: why postgres?
by AC on Wednesday 23/Feb/2005, @13:50
|
MPL isn't GPL compatible; there's not even a reason to look further. We're going to have to use the client libraries for these databases.
I don't see any reason not to use Postgres; there are loads of ways that all of this could be done, but the datastore is the boring part and Postgres fits our requirements. I don't really see a reason to look further at the moment.
|
[
Reply To This | View ]
|
Re: why postgres?
by Scott Wheeler on Wednesday 23/Feb/2005, @13:53
|
Err, that was me. Konqueror is having fun with my cookies.
|
[
Reply To This | View ]
|
Re: why postgres?
by Marco Menardi on Wednesday 23/Feb/2005, @15:01
|
I've never heard of problems with FirebirdSQL and GPL, since you have to connect with the database, not include his code. Maybe their "modified" MPL is modified enought to be able to interface with GPL programs ;) But I'm not a lawyer.
I was replying to your message about PostgresSQL vs MySQL, and I'm sure you will be surprised on Firebird performances, low footprint, high stability, low manteniance needs, etc..
So mine was just a suggestion, since if you "don't see any reason not to use Postgres", I don't see any reason to use Postgres instead of Firebird ;)
So would be great if you could have a look also at Firebird :)
thanks
|
[
Reply To This | View ]
|
Re: why postgres?
by Ian Monroe on Thursday 24/Feb/2005, @00:11
|
Well, I'd assume the client libraries for FirebirdSQL are in MPL as well. You do have to link againist those.
|
[
Reply To This | View ]
|
Re: why postgres?
by Marco Menardi on Thursday 24/Feb/2005, @01:00
|
Well, I use Firebird and, at the moment, my program is in Delphi under Windows, so I'm not an expert and I don't know what "client libraries" you need.
I know, for instance, that JCA/JDBC Driver:
http://www.firebirdsql.org/index.php?op=devel&sub=jdbc
is distributed free of charge under the GNU Lesser General Public License (LGPL).
I don't know about ODBC/JDBC Driver
http://www.firebirdsql.org/index.php?op=devel&sub=odbc
or ADO.NET Data Provider
http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
but probably the license is included in the package you can download.
In any case, if you visit the main site I suggest you http://www.firebirdsql.org/ probably you can understand more and better.
Thanks again
|
[
Reply To This | View ]
|
Re: why postgres?
by brockers on Thursday 14/Apr/2005, @16:39
|
So KDE is going to choose a database that is LGPL because of licensing restrictions from using a straight GPL'ed database when we use a GPL'ed toolkit to do EVERYTHING related to Qt? I hope this is not really the case because it would seem to lend credibility to the Gnome-huggers who say that KDE is worthless as a general purpose business desktop because QT is GPL'ed and not LGPL'ed. If we can use QT in KDE why not MySQL? Don't get me wrong, I don't have a problem with Postgres, I just hate to see KDE use the same argument against something that has been leveled against us.
|
[
Reply To This | View ]
|
Have you looked at MetaKit?
by Mr. Fancypants on Wednesday 23/Feb/2005, @14:08
|
(See http://www.equi4.com/mkdocs.html)
It seems to support most of the usual relational operators without the yuckiness (quoting differences, various conventions for parameters, non-standard syntax, etc.) of SQL.
There also seems to be support for concurrent reading and writing (maybe only 1 writer at a time, I'm not sure) and it looks quite mature.
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by ac on Wednesday 23/Feb/2005, @14:43
|
Please stop listing existing databases.
I'm sure that Scott and Aaron know that there are many DBs out there.
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by anon on Wednesday 23/Feb/2005, @15:20
|
We're using in akregator now. metakit is very good.
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by Aaron J. Seigo on Thursday 24/Feb/2005, @00:17
|
as an embedded database it looks good. but we don't need an embedded database, we need a database that can be accessed simultaneously and, preferably, over a network. the TODO list for this project is already big enough without adding "write a scalable RDBMS" ;)
once the first edition is out using an external RDBMS then perhaps all the data storage fans can swoop in with their super dooper file systems and coolio ultra-tiny database-like engines and experiment/optimize that area of the software.
but it's not the interesting nor a critical part of the project. =)
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by Pat on Thursday 24/Feb/2005, @07:49
|
maybe u could make the data storage part "pluginable" so that developpers could easily implement different db backend à la kexi or even like that damn amarok while you could focus on the postgresql part :)
|
[
Reply To This | View ]
|
Re: why postgres?
by Carlo on Wednesday 23/Feb/2005, @14:11
|
Oh well, please stay with Postgres and don't give a flying fart on those wanting sqlite or some java based db. Very good choice!
|
[
Reply To This | View ]
|
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
|
[
Reply To This | View ]
|
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 ]
|
|
Re: why postgres?
by Bryan Feeney on Wednesday 23/Feb/2005, @09:20
|
SQLite would be really great.
Would it be possible to specify a list of directories to be indexed/monitored with the option to recurse through the directory structure and make it available for searches by other users.?
E.g.
I would have /home/bryan, and mark it recursive and hidden
As root I would add /usr/share/music (all my oggs etc., shared between users), and mark it as recursive and visible to all.
Other users do the same. The list of public search folders is stored in /etc/indexeddirs. Each person's private list is stored in ~/.indexeddirs. For each directory have a sqlite DB in the root of that directory called .dirindex.sqlite or something.
Then when someone does a a search, open and concatentate the private list (~/.indexeddirs) and the public list (/etc/indexeddirs), open all the directories, and search through each?
That might be a bit much though, I don't know the specifics of search. Is this being developed using Qt4 or KDE/Qt. It'd be cool if the backend was developed using Qt4, so it would be a nice small dependency that other projects could use.
|
[
Reply To This | View ]
|
Re: why postgres? SQLite is the way to go!
by ac on Wednesday 23/Feb/2005, @12:08
|
SQLite is the way to go, small, fast, the Right Thing for this task
|
[
Reply To This | View ]
|
Re: why postgres? SQLite is the way to go!
by Aaron J. Seigo on Wednesday 23/Feb/2005, @13:12
|
> small,
yes, it is small. pgsql isn't exactly huge however. the postgresql system isn't very large. the rpms on SUSE are ~10MB (includes the docs, stored procedure language and what not) and it's memory usage is also pretty good. we're not talking 100s or even dozens of MB of ram.
> fast,
not for the types of queries that are required.
and, as Scott mentioned above, this needs to support multi-process access which means locking and the whole bit. sqlite is great for the purposes it was intended for; this isn't one of them. =)
|
[
Reply To This | View ]
|
Re: why postgres? SQLite is the way to go!
by David on Wednesday 23/Feb/2005, @14:06
|
There are some issues with using SQLite which I think Scott has gone over above. For what SQLite does it is very, very good, but probably not what they're looking for for the purpose of this.
However, if you've ever built KDE you'll know just how many other projects KDE depends on. Postgres is actually small-fry compared to the total.
|
[
Reply To This | View ]
|
Re: why postgres? SQLite is the way to go!
by ac on Wednesday 23/Feb/2005, @18:45
|
I really don't care what database backend an application uses, but it would be nice if I didn't have to run 5 different DB servers in the background just to use KDE.
|
[
Reply To This | View ]
|
Re: why postgres? SQLite is the way to go!
by Ian Monroe on Thursday 24/Feb/2005, @00:20
|
This is a very valid point... kdelibs requiring a database (which it sounds like it will be doing) will make things a lot easier for a variety of KDE programs that currently have to come with packaged with sqlite.
|
[
Reply To This | View ]
|
Re: why postgres? SQLite is the way to go!
by Aaron J. Seigo on Thursday 24/Feb/2005, @00:21
|
> but it would be nice if I didn't have to run 5 different DB servers in the
> background just to use KDE
i don't think you will. at most you may have to run one, and even that may well turn out to be optional (at the cost of the features that rely on it).
|
[
Reply To This | View ]
|
Re: why postgres? SQLite is the way to go!
by Arun Raghavan on Friday 02/Sep/2005, @20:06
|
While my first reaction was, "*Groan*, WhyTF do I need to run a DB server on my PC just to have a good desktop experience", I think this is a good decision. Modern systems will not be loaded excessively by a Postgres server running in the background, and the payoff would be *much* more than worth it.
But I do wish it could all be independent of the actual database used. Or at least give a choice between 2-3 popular databases. Maybe eventually, closer to productization, when such pragmatic issues are more important.
|
[
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)
