[Digikam-devel] [Bug 267131] Digikam config and data cannot be moved, absolute paths embedded in database and digikamrc

[Ilia K.]

https://bugs.kde.org/show_bug.cgi?id=267131


Ilia K. <mail4ilia at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail4ilia at gmail.com




--- Comment #2 from Ilia K. <mail4ilia gmail com>  2011-05-02 04:57:28 ---
Hi,
sorry for the lengthy post, but I tried to be constructive and not only state
a problem, but propose a viable solution. What do you, developers, think?

This issue may also break the following use case (I actually need this!):
Alice and Bob use shared MySQL server for digikam database. The files
themselves are shared over NFS, but Alice mounts them on her computer as
/home/alice/Pictures and Bob on his computer as /mnt/photoes.

Other affected use cases may be thought of: DB & files on mobile HDD, backup
restoration, mount point move/rename, etc.

IMHO, DB should contain all file paths relative to each collection root,
e.g. use UUID as a first element of the name, e.g.
/mnt/photoes/album/file.jpg
becomes
a1a88989-5fb5-4621-b539-522f5aa02ff1/album/file.jpg

The question is where to store the paths for collection roots. For above
usecase, it seems logical to store them in local config.

There is a broader issue of guessing that different absolute file names refer
to the same object:

Alice configures her digikam and adds photos (DB records are created). Now Bob
wants to access the same files and DB entries. Although he knows path to the
collection, how can he know UUID? A possible solution: digikam writes uuid.txt
in a collection root with collection UUID, but I don't like it. What if
collection is read-only? What if Bob now uses his own DB?

Maybe, a better solution: allow to query collection list from DB and present
it to the user along with a descriptive name and probably a path hints (last
two are given by the user who already configured an access to the
collection). So collection settings tab can look like the following mockup.
ASCII tables and their headers are used just to signify the layout. Legend and
behavior are described in the next comment (presumably, comment #3 ).

---------------------------------------------------------------------------
Below are the locations of root albums used to store image files.
Write access is necessary to be able to edit images in these albums.
(Removable media and remote file systems are supported)

You have configured the following collections:
| Type  | Name         | Path                  | Action      |
|-------+--------------+-----------------------+-------------|
| [LOC] | Bob Photos   | /home/bob/Pictures    | [Del]       |

----

Other users of your database have configured the following collections.
To access these collections you will need to provide a path to image files
from your computer.

| Type  | Name         | Possible Path(s)      | Action      |
|-------+--------------+-----------------------+-------------|
| [LOC] | Alice Photos | /home/alice/Pictures  | [Add] [Del] |
|-------+--------------+-----------------------+-------------|
| [MED] | NIKON D90    | /media/NIKON D90      | [Add] [Del] |
|-------+--------------+-----------------------+-------------|
| [NET] | Archive      | /mnt/server/photos    | [Add] [Del] |
|       |              | /media/archive/photos |             |
|-------+--------------+-----------------------+-------------|

----

[Add new collection...]
---------------------------------------------------------------------------

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.