[Digikam-devel] [Bug 134594] New: WISH: Independent database backend support for increased usability (MySQL/PostgreSQL etc)

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         
           Summary: WISH: Independent database backend support for increased
                    usability (MySQL/PostgreSQL etc)
           Product: digikam
           Version: 0.9.0-beta2
          Platform: Slackware Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: yallaone gmail com


Version:           0.9.0-beta2 (using KDE KDE 3.5.4)
Installed from:    Slackware Packages
OS:                Linux

digikam currently is very closely linked to sqlite. This works well for small installations, but is beginning to cause a wider range of problems for future scalability and usability.

Thus I would like to re-initiate the debate on making digikam database agnostic, allowing others to write an optional mysql (or postgresql) plugin for use in addition to default sqlite. This similar to the approach taken by the amarok development team.

More and more users store/share their images on NFS volumes which does not work with sqlite, and while sqlite blames NFS implementation in linux kernel, the end result is that digikam does not function in NFS environments. The use of auto-mounted NFS home directories grow, and in multi-user scenarios such as families wanting access to the photo album from multiple users it simply doesn't work, even with the --enable-nfs-hack option

Storing data in a mySQL database makes easier access for web frontends so that albums complete with comments and data can be shared over the web

Future integration with other applications, such as for instance mythtv. Users don't want to watch pictures just on their PC anymore, but also on the TV. By having a flexible database approach, it is easier for mythtv/freevo developers to access the already classified data from digikam and showing them on the TV. Thus enabling increased KDE inter-application interaction.

Once again I realize this has been discussed earlier, but it seems to have always been very quickly dismissed as "not going to happen". Would it be possible to bring this up for discussion and if possible explore positive and negtive consequences of this?

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

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |setup



------- Additional Comments From caulier.gilles free fr  2006-09-24 20:21 -------
Halim,

We are concient of the SQlite limitation and there are a lot of report about to use an universal database interface with digiKam.

I'm agree with you than sqlite is a limitation for digiKam, especially to use a remote database (using NFS for example). I would to start DB stuff later than 0.9.0 because it a big job.

Marcel, what do you think about ?

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

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From marcel.wiesweg gmx de  2006-09-24 20:43 -------
In a completely different context, we talked about consolidating the database code spread in albumdb, scanlib, ioslave in one lib.
For this we will need to define database interfaces anyway, so it gives an opportunity to abstract the db interface.

After 0.9.0 of course.

Providing the interface is the one thing, coding and maintaining a db backend the other thing. But at least we could then say "here is the interface, code a plugin" ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From mikmach wp pl  2006-09-24 21:48 -------
Qt4 has extended SQL bindings. Maybe wait for Digikam on Qt4 for that?
I think Amarok is considering using just Qt backend for future database.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[F.J.Cruz]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From fj.cruz supercable es  2006-09-24 22:38 -------
There are too many entries in BKO related to digikam db problems. While digiKam is an adavanced app in a lot of aspects, the db stuff is really a fault.

INMO, more advanced db interface and backends are needed by digiKam. We are making a hard work to have the best metadata write and read tool, the best tags system, the best image editor, a color managed app, etc. but, if we have a poor db stuff, well, we have a great hole in the base of the app.

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

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From caulier.gilles free fr  2006-09-25 07:45 -------
Thanks for your viewpoint Paco. I'm totally agree with you.

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

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|setup                       |Database
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From marcel.wiesweg gmx de  2006-09-26 13:43 -------
Seb Ruiz is blogging about Amarok's considerations to move:
http://www.sebruiz.net/162

Docs on Qt4's SQL support can be found here:
http://doc.trolltech.com/4.2/qtsql.html

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

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From caulier.gilles free fr  2006-09-26 13:57 -------
I'm agree with you Marcel. Qt4 is exactly what we need about to make a new DB interface.

This is want mean that we will delay this task later to have ported digiKam to Qt4/CMake, of course, later 0.9.0 relase.

Other point to talk is about the database structure : if we use new DB backends, we can change something in structure at the same time ?

There are other files in B.K.o witch require database changes, especially to perform search about photograph informations, like aperture for example, or GPS coordinates.

I think we can change database structure at the same time because in all cases, we will need an tool to migrate from sqlite to new DB backend. We just need to take a care about the new structure to be more flexible than the actual.

Question : Marcel, Paco, are you already some experiences about database?

Personaly, i have already managed database used PHP. I know all base of DB management, but i'm not a specialist (:=))).

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

[F.J.Cruz]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From fj.cruz supercable es  2006-09-26 23:19 -------
I'm working with databases at work, but in a web environment. With mysql, postgres and oracle from php and java. Some time ago, I wrote some apps for personal use which worked with mysql, using qt db plugins.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         
mikael.lammentausta student savonia-amk fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
      everconfirmed|0                           |1



------- Additional Comments From mikael.lammentausta student savonia-amk fi  2006-09-26 23:23 -------
*** This bug has been confirmed by popular vote. ***
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[F.J.Cruz]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From fj.cruz supercable es  2006-09-26 23:38 -------
If anybody want to have a look to the actual qt 3.3 sql support, this is the link:

http://doc.trolltech.com/3.3/sql.html
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From yallaone gmail com  2006-09-27 12:31 -------
Would it make sense to at least run this discussion by the developer of other
software that digikam is likely to be cooperating and coexisting with?

I'm firstly thinking of mythTV / freevo. I assume (haven't done a poll - might
be worth while) that most computer users prefer to manage/sort their pictures
on their computer, but to share them with friends and family on the web and
in the living-room TV. I don't know much about Myth/Freevo developers, but it
seems clear to me that end-users would greatly benefit from some kind of
interaction! Same would go for web-photoalbum projects such as for instance
coppermine.

Realistically, a common database format for myth-photoalbum, freevo, digikam,
coppermine and others might be difficult to achieve, but at least a well
documented API so that other primary viewing-apps can benefit from the work
done through digikam.

Thoughts?

On Tuesday 26 September 2006 13:57, Gilles Caulier wrote:

> Other point to talk is about the database structure : if we use new DB
> backends, we can change something in structure at the same time ?
>
> There are other files in B.K.o witch require database changes, especially
> to perform search about photograph informations, like aperture for example,
> or GPS coordinates.
>
> I think we can change database structure at the same time because in all
> cases, we will need an tool to migrate from sqlite to new DB backend. We
> just need to take a care about the new structure to be more flexible than
> the actual.

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From mikmach wp pl  2006-09-27 13:24 -------
I think common database is impossible to achieve - also various apps
have different goals, mythTV is even different medium. Good
documentation is always wonderful thing.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From kde colin guthr ie  2006-09-27 22:39 -------
In reply to comment 11:

I have posted a few times to the MythTV dev mailing lists about my intensions to "integrate" Digikam and MythTV but it is not through a direct route. I am currently working on (and discussing on the Kipi ML) at making the Kipi Gallery plugin better. By making the Gallery "Export" as it is now, into more of a "Sync" it will become very easy to publish your photos on your website.

The second part of what I want to do will be to implement support in MythGallery for reading remote Galleries (e.g. those of your friends or your own personal one.)

So, if I use Digikam to manage my photos, then use the Gallery Kipi Plugin to publish them to my website, I can then use MythGallery to view my website's gallery!!!

Like I say it's a little indirect, but it would achieve the desired results! At least for me! (I want it on my website anyway and as it happens I host my website from my internal network so the latency would be minimal, but suitible caching in MythGallery for remote galleries should make it work nicely for properly remote galleries).
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Jaroslaw Staniek-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From js iidea pl  2006-11-02 20:20 -------
Other idea is to look at KexiDB, KDE4's database module. With QtSQL you'll still have a problem with SQLite dependency. KexiDB have maintained and builtin SQLite version since early 2004.

Non-GUI parts of KexiDB are already fully ported to KDE4.

You'll also get PostreSQL, MySQL support OOTB, and integration with querying tools.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From caulier.gilles kdemail net  2006-11-02 21:09 -------
Thanks Staniek for this information.

Is KexiDB have been used by ShowImg or Amarok ?

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

[rosenauer]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From rosenauer gmx at  2007-03-28 14:38 -------
This problem also occurs with SMB/CIFS-shares and is not mentioned in the docs. I do not understand why this is a problem with sqlite since digikam only sees a local mount point and everything else is abstracted over the VFS or am I mistaken?

It's a shame that I cannot use this excellent app in my environment, because I use a separate shared storage for all media stuff, which is (as already mentioned) quite a common usecase I would say.

Any progress on the Qt4-usage? Most people will have Qt3 and Qt4 installed anyway now that more and more apps are ported to be ready for KDE4, so it would be a good solution IMO to migrate digikam too and solve this long standing issue in one row...
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From caulier.gilles gmail com  2007-03-28 14:54 -------
>Any progress on the Qt4-usage? Most people will have Qt3 and Qt4 installed anyway >now that more and more apps are ported to be ready for KDE4, so it would be a >good solution IMO to migrate digikam too and solve this long standing issue in >one row...

Yes... Googd news

Monday, Marcel i sent to me a mail to said than the DB interface is under developement using Qt3 and current implementation of digiKam from svn...

The code is re-factorized and polished. It's not complete and not yet on svn. The code still on Marcel computer's.

Marcel need more time to test indeep. DB stuff is a tiedous job...

He said than the new interface is ready to use another DB backend than sqlite. Of course nothing is yet tested in this way but the future is back.

Marcel is in hollidays actually and not available. I think than he will proposal a patch as soon to have feedback.

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134594         




------- Additional Comments From yallaone gmail com  2007-03-29 16:22 -------
This is _excellent_ news - thank you so much for your continued work on this.
While this sudden burst of joy may be off-topic, I just wanted to thank you
for not forgetting about this important request.

Thanks again, and happy coding!

On Wednesday 28 March 2007 14:54, Gilles Caulier wrote:
[bugs.kde.org quoted mail]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel