Bug 125474 - MAINTENANCE : possibility to merge digiKam databases
Summary: MAINTENANCE : possibility to merge digiKam databases
Status: CONFIRMED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Migration (show other bugs)
Version: 8.1.0
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-13 09:29 UTC by Henning Ströker
Modified: 2024-04-22 07:26 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henning Ströker 2006-04-13 09:29:41 UTC
Version:            (using KDE KDE 3.5.0)
Installed from:    SuSE RPMs

Sometimes it will happen that two digikam images databases should be merged. That is not only the import of the images of one database into the other. More important is that the keywords of both databases are merged into a new one.
Comment 1 thm 2006-04-25 13:27:22 UTC
Why not allow to view several databases at the same time?

Example: 
I'd like to see/search images that come from several media. 
From my personal laptop I would be able to view at the same time the local database as well as the one on my server and the one stored on a DVD.

This way I could navigate thought my "holiday" keyword whatever the source is. But If i want to physically merge database, I can simply move the file from a database folder to an other database folder (as one database is dedicated to a folder) : but I totally agree that the keywords must follow.
Comment 2 Luke 2007-02-24 13:07:06 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 caulier.gilles 2007-11-06 16:15:49 UTC
SVN commit 733526 by cgilles:

digiKam from trunk (KDE4) : add Multiple Roots Album Path on setup.

With new database interface implemented by Marcel, digiKam can use more than one root album path as collection of images.
digiKam database file is now stored in a customized place wich still in local and can be different than roots album. 
This is want mean than read only, remote repository, and disconnected repository are fully suported as well.

These collection types are able to use:

- Local drive.
- Remote drive (NFS/Samba) previously mounted in local file system. 
- Removable drive as CD/DVD/USB hard drive.

Each collection set in configuaration dialog page can be named to be identified easily into Album GUI/Folder view.

There is a fresh screenshot of Collection Setup page at this url:

http://digikam3rdparty.free.fr/Screenshots/digikamKDE4_14.png

TODO: in album gui, and especially in album folder view, we need to add a better support of collections name. 

CCMAIL: digikam-devel@kde.org
BUG: 107871
BUG: 114682
BUG: 122516
CCBUGS: 125474



 M  +434 -67   setupcollections.cpp  
 M  +13 -1     setupcollections.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=733526
Comment 4 Jasper 2008-04-10 00:22:56 UTC
When using my laptop to save images to I run out of space very often and would like to export images to dvd or other drive.
 It would be very convinient if digikam could
i) Automate the DVD ISO creation process by extracting images and database entries, and creating an ISO with images and database in iso root. Also with the option of the DVD being a backup (i.e images left in original album location) Or export (i.e images reomevd from original album location)
ii) Similar for copying to other locations such as nfs, samba share, removable drive etc. Extract images from current albums and add database entries to root of removable media, or wherever they ought to be on the removable media... this is a little less trivial I understand
iii) Digikam be aware that it has done these things and continue to store the database entries, file list etc. and thumbnails fo exported images such that they can be browsed without the media present. AND that these external collections are added to the list of albums such that they can be removed/merged etc.
iv) If database and images are on external media, that they can be imported into the local database as external media with thumbnails being generated and stored locally, and database entries stored locally, but as above referenced as an external collection

A more wordy description of how the ignorant non coder imageines this process to work: For a usb drive  mounted at /media/mybigusbdrive with the images in /media/mybigusbdrive/Media/Images/ with some unique id, I can add an external collection for the removeable disk, with either the unique id or mount point 
(i.e ID or /med/mybigusbdrive), and then the image root directory (i.e Media/Images). This is possibly nothing new with the new album framework allowing multiple roots... except that if digikam is aware of the mount point or uniqu id that it could be aware what external collections were connected such that images coulb e exported. 
 Later on when I remove the disk from the usb enclousure and put it in the file server so its mount nfs, samba .. whagtever, I can modify the album information to reflect this change. i.e new mount point ID prob. not relevant, not a usbdrive but a network mount, new images root etc. 

DVD's are obviousley a special case as read-only media with no changes nexcesarry or really possible. 
 In all cases I imagine being able to browse the thumbnails and if I want to edit/use etc. an image in an external collection that Digikam tell me to insert such and such a disk or drive, or try (if set to) to mount the nfs, samba etc...

As I invisage image collections being long term entities i.e 10years+ (and having just been burned by 400G drive dying with ALL my images unbacked up being lost until I fork out for recovery 8~) I see this functionality as highly important for any image management programme.

Comment 5 Arnd Baecker 2008-04-10 09:45:11 UTC
Jasper, 

this is indeed a very important issue.
Note that with digikam 0.10, multiple root albums will be possible.
So this is a first stepp in this direction.
Also note that backup on DVD is also discussed in 
http://bugs.kde.org/show_bug.cgi?id=113715

Concerning backup and data integrity: I can highly recommend this text
http://www.gerhard.fr/DAM/
So even if one has a backup, we need to introduce measures to 
verify and detect data integrity problems ....
Comment 6 Simon Oosthoek 2010-09-27 20:50:12 UTC
I'd like to add a usecase... I posted the same message on the digikam-users mailinglist.

------------------------------------------------
currently I have two semi-separate digikam collections, one on a desktop 
PC and another on the laptop. For practical reasons (desktop is in the 
attic always on, laptop is downstairs, easy access) the collection on 
the laptop contains most of the newer files and recently I've started to 
add tags there as well. On the desktop I already had a digikam 
collection and there are some tags there as well. I sometimes rsync the 
laptop's collection to my desktop, so most of the photos on my laptop 
are also on the desktop, obviously the digikam db is largely unaware of 
this.
Most photos are two files, one ARW and a JPG, sometimes I have more 
files for a single shot generated by the gimp from the ARW file. When I 
tag files, I try to tag both the raw and the jpeg versions, but digikam 
doesn't write tags to the ARW files, so when I transfer the files to my 
desktop, half the images lose the tags.

How can this be resolved properly?

I know digikam can now use a centralised mysql db. One scenario might be 
that I use mysql on the desktop pc and use NFS+remote mysql from the 
laptop to have only a single store of images+metadata. This is fine for 
at home, but when I go on holiday and my laptop is used to store the 
images during the holiday (in digikam of course), I have to merge stuff 
again. And of course, the first time I still need to combine the two 
collections...

I can imagine a tool that makes it possible to merge a (remote) 
collection into the current one, using some user interaction to input 
the location of the images and the sqlite/mysql database and then copy 
both the images and the metadata to the current collection. if the file 
is already in the current collection, users should be able to select a 
solution (e.g. they might be in different relative locations or they 
have the same name, but have different tags or even have the same name, 
but are completely different images (different cameras with same 
filename structure, counter overflow+reset))

does such a tool exist? or should this be a wish filed to bugs.kde.org?

If possible I'd love something like this to be available as a commandline replacement for rsync...

Cheers

Simon
Comment 7 caulier.gilles 2011-12-15 09:34:30 UTC
Henning,

This file still valid using multiple root support introduced with 1.x serie ? Can you test with digiKam 2.x ?

Gilles Caulier
Comment 8 Justin Zobel 2021-03-09 05:51:43 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.
Comment 9 michael2macdonald 2023-04-28 23:26:35 UTC
(In reply to Justin Zobel from comment #8)
> Thank you for the bug report.
> 
> As this report hasn't seen any changes in 5 years or more, we ask if you can
> please confirm that the issue still persists.
> 
> If this bug is no longer persisting or relevant please change the status to
> resolved.

This bug still exists. There is no way to merge two digikam databases. This use is even more important now that remote databases and root paths are supported because it increases the likelihood that someone would be in a situation where they need to merge multiple databases (Such as merging the databases from two computers [like a laptop and desktop] into a new central server or NAS).

I am changing the platform to "undefined" and "All" as this is a universal bug in digikam, and updating it to the latest version of digikam it is present in (0.8.2 -> 8.1.0).

Also, maybe we should change the component from "Maintenance-Database" to "Database-Migration" as I think it would fit better there.
Comment 10 kde.protector622 2024-04-22 07:26:05 UTC
I'd really appreciate that feature and find it very helpful!