sqlite in kdelibs
mike at quaking.demon.co.uk
Thu Jan 20 17:27:09 GMT 2005
On Wednesday 19 January 2005 15:00, ian geiser wrote:
> This is insane. Why the heck do we need SQLite in KDE libs when its built
> in to Qt SQL?
Based on my experience with Rekall, and haveing looked at the Qt SQL classes
(unless they have been radically extended) then if you are writing a specific
purpose app that *knows* what sort of database server it is talking to, then
the Qt SQL classes are probably fine.
But if you want to write anything more generic (either, a general purpose app
like Kexi or Rekall; or an app that can be reasonably database server
independent) then the Qt SQL classes are pretty well useless, since they do
not expose anything like enough information about the database server.
As an exercise: try to write an app using the Qt SQL classes which can insert
a row into a table and then retrieve the server-generated primary key for
that row, without coding any knowledge about, or tests for, what database
server the app is talking to.
> If anything we should be adding Qt sql config classes into
> KDE libs. I have such a lib that has a stock config gui for managing Qt
> sql database connections and providing the correct Qt sql classes. You
> basicly call the method sxDBHandle(const QString &profile) and it hands you
> back the setup database connection. Very similar to the ODBC config guis
> of ye old days but for Qt sql drivers. There is absolutely no good reason
> under any circumstances that we should even propose duplicating Qt sql in
> KDE libs. Its not worth the extra bug reports. In the last 4 years of
> commercial Qt development with Qt sql I have only run into one instance
> where it had problems, and that was because the idiot client wanted to
> store 1+MB blobs in the database. Let the trolls maintain it and fix the
> bugs. If people want to re-invent the wheel let them do it in their own
> modules and bug databases.
> If anyone wants to play with my config stuff I can lgpl it and put in in
> nonbeta. Basicly its a QWidget that stores to a QSettings object, but
> conversion to a control panel and kconfig would be trivial. There are some
> simple db managment methods for adding and dropping a database, but those
> should be replaced with something more complete, or removed all together.
> -ian reinhart geiser
> On Wednesday 19 January 2005 08:41 am, Jaroslaw Staniek wrote:
> > >Besides, wouldn't databases be something pluggable. E.g. using ODBC.
> > >That way data from many applications can be combined at database level.
> > >This would be quite simple if SQL strings was externalized into config
> > > files. If no other database was specified, one could fall back on SQL
> > > lite.
> > Since 2003, KexiDB is a candidate for being exactly such a solution for
> > kdelibs. KexiDB module uses SQLite almost from the begging and provides
> > library and set of widgets (table grid, and recently - forms). Database
> > drivers are provided as plugins (MySQL, PostgreSQL drivers also
> > available).
> > Please notice that KexiDB is also (except in Kexi) used by ShowImg
> > (digiKam competitor) for image catalogs, thus it's so far, application
> > which is doing things properly without rewriting KexiDB functionality.
> > Btw, it's also planned to develop optional Qt-only KexiDB version.
> > see
> > http://www.kexi-project.org
> > http://koffice.org/developer/apidocs/kexi/html/
> > for more info, or meet us at #kexi irc channel.
More information about the kde-core-devel