Dependency on Qt SQL module

[Marcel Wiesweg]

Hi,

you might have guessed from the commit that I cc'ed on the list, from tonight
the KDE4 / trunk version depends on the Qt4 SQL module.

The reason I mention this explicitly is that most distributions package this
as a separate package. I dont know if this is installed per default.

What we currently need is the Qt driver for sqlite3, so this module is just a
thin wrapper between digikam and libsqlite3 which we depend on anyway. On
Gentoo, I have to set a use flag to pull sqlite3 support in when compiling.

There is a configure check and a runtime test, so it will tell you what is
missing ;-)

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Marcel,

Like we use now the Qt SQL wrapper, i suppose than we can use easily another DB backend as MySQL... Right ?

Advantage to use MySQL (for ex.) is certainly to have a transparent removable media device as root album path witch store digiKam database...

Gilles

2007/8/13, Marcel Wiesweg <[hidden email]>:

Hi,

you might have guessed from the commit that I cc'ed on the list, from tonight
the KDE4 / trunk version depends on the Qt4 SQL module.

The reason I mention this explicitly is that most distributions package this
as a separate package. I dont know if this is installed per default.

What we currently need is the Qt driver for sqlite3, so this module is just a
thin wrapper between digikam and libsqlite3 which we depend on anyway. On
Gentoo, I have to set a use flag to pull sqlite3 support in when compiling.

There is a configure check and a runtime test, so it will tell you what is
missing ;-)

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Marcel,
>
> Like we use now the Qt SQL wrapper, i suppose than we can use easily
> another DB backend as MySQL... Right ?

We need to test that the SQL we have works with MySQL. I am not familiar with
SQL dialects. Looking at amarok, there may be issues with specifiying the
length of text fields. Anyway I expect MySQL to have at least the level of
support for SQL that SQLite has...

>
> Advantage to use MySQL (for ex.) is certainly to have a transparent
> removable media device as root album path witch store digiKam database...
>
> Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Colin Guthrie-6]

Marcel Wiesweg wrote:
>> Marcel,
>>
>> Like we use now the Qt SQL wrapper, i suppose than we can use easily
>> another DB backend as MySQL... Right ?
>
> We need to test that the SQL we have works with MySQL. I am not familiar with
> SQL dialects. Looking at amarok, there may be issues with specifiying the
> length of text fields. Anyway I expect MySQL to have at least the level of
> support for SQL that SQLite has...

If someone can do a dump of SQL cmds I can run thorugh and check/rewrite
them for MySQL. I use MySQL a lot so shouldn't be too hard.

You'd need at least version 4.1 or 5 is you use subselects tho'.

Col

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Marcel,

digiKam still depand of libsqlite version 3 to be compiled ? If no, depency rules into main CMakeList.txt can be removed...

Friendly

Gilles

2007/8/15, Marcel Wiesweg < [hidden email]>:

> Marcel,
>
> Like we use now the Qt SQL wrapper, i suppose than we can use easily
> another DB backend as MySQL... Right ?

We need to test that the SQL we have works with MySQL. I am not familiar with
SQL dialects. Looking at amarok, there may be issues with specifiying the
length of text fields. Anyway I expect MySQL to have at least the level of
support for SQL that SQLite has...

>
> Advantage to use MySQL (for ex.) is certainly to have a transparent
> removable media device as root album path witch store digiKam database...
>
> Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

>
> digiKam still depand of libsqlite version 3 to be compiled ? If no, depency
> rules into main CMakeList.txt can be removed...

We dont directly link to libsqlite3 any more, but we need to sqlite3 plugin
from the Qt SQL module. Missing a configure check that the Qt SQL module
contains this plugin, I left the direct sqlite3 check in place.
Feel free to change.

Marcel

>
> Friendly
>
> Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/19, Marcel Wiesweg <[hidden email]>:

>
> digiKam still depand of libsqlite version 3 to be compiled ? If no, depency
> rules into main CMakeList.txt can be removed...

We dont directly link to libsqlite3 any more, but we need to sqlite3 plugin
from the Qt SQL module. Missing a configure check that the Qt SQL module
contains this plugin, I left the direct sqlite3 check in place.
Feel free to change.

Well, normally, if QT Sqlite3 database plugin is installed, sqlite3 library will be installed too to work properlly.

Currently, digiKam sqlite3 depency is about devel package to compile it. If we don't need it to compile digiKam, i propose to remove this depency and add a new check to Qt sqlite plugin instead. No need to dupplicate it.

I would to have the viewpoints from packagers in this room please.

Gilles


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel