Bug 137694

<<However, it should be REALLY EASY to provide e.g. a command-line option to store  the database file in the user's home directory
>>

I agree. I would suggest to add 2 command-line options to start digikam :
-f to specify the full path to digikam3.db
-d to specify the full path to the albums root directory

Use cases :
- be able to have different independant collections (eg professional, personal, etc...)
- be able to share one collection with other users (eg pictures on a shared directory or on NFS/SMB volume), but with one's own tagging/comments (eg shared directory could be read-only)
- provide a quick hack to these network path problems

Fabien,

I recommend you look this option from .configure script :

  --enable-nfs-hack       Enable a hack for album libraries on a nfs mount,
                          which causes the database to be saved in
                          $HOMEDIR/.kde/share/apps/digikam/directoryname.db
                          default=disable

This is an old feature done by Renchi Raju to solve temporally the NFS problem with SQlite DB...

Gilles

I have seen a lot of people suggest the --enable-nfs-hack as a solution, but for me (running Ubuntu) this does not seem to be available:

$ digikam --help
Usage: digikam [Qt-options] [KDE-options] [options] 

A Photo-Management Application for KDE
Using Kipi library version 0.1.4

Generic options:
  --help                    Show help about options
  --help-qt                 Show Qt specific options
  --help-kde                Show KDE specific options
  --help-all                Show all options
  --author                  Show author information
  -v, --version             Show version information
  --license                 Show license information
  --                        End of options

Options:
  --detect-camera           Automatically detect and open camera
  --download-from <path>    Open camera dialog at <path>

Maybe it's a compile-time option, in which case it doesn't help the average user much (if distros don't include it).

I think Fabien's suggested options are EXACTLY WHAT WE NEED. How soon can we have them? Please... :-)

--enable-nfs-hack is a compilation option avaialble on .configure script not like a digiKam command line parameter.

Also a new DB interface will be done later 0.9.0 release to be able to work on a remote digiKam Albums collection.

Gilles Caulier

Gilles, this is not only about solving problems around network storage, but also to have more flexibility with digikam.
See my use cases :)

I know a lot of work will be done on Db access after the 0.9.0 release.
But, it will take months, maybe 1 year to implement the new db backend, especially if you want to use qt4 with it.

I think adding 2 optional cmd-line options could be done in 0.9.1 or 0.9.2.

I already tried to change the full path to digikam3.db and it works (one change in 3 files) :

digikam/albummanager.cpp:    QString dbPath = "/localhome/fabien/Digikam/digikam3.db";
digikam/upgradedb_sqlite2tosqlite3.cpp:    QString newDB= "/localhome/fabien/Digikam/digikam3.db";
kioslave/sqlitedb.cpp:    QString dbPath = "/localhome/fabien/Digikam/digikam3.db";

Could someone with the proper authority (Gilles?) comment on Fabien's sugestion?
To me, a regular user, it seems like exactly what is needed...and it looks like a simple addition to the application. As the months go by without anything (seemingly) being done about the situation, why the big resentment to Fabien's suggestion?

Since I am unable to user digiKam, I have now started using GThumb, Picasa and F-Spot. While I don't find any of them to match digiKam's features, Picasa seems to be the closest. So for others with the same digiKam problem as me, I'd recommend taking a look at Picasa. Who knows, I might even get used to it to the point where I give up on pushing for network storage support in digiKam...

I have not yet commented this thread, because network support is planed in the future, especially when we port digiKam to Qt4, to provide a new database backend. Actually we study the better way to do it with Marcel.

Gilles

This bug has been there for at least half a year, and I'm guessing a port to Qt4 and/or implementation of a new database backend is at least half a year into the future (not to mention the time it takes to roll down through the distros into the hands of users).

I wish the digiKam developers would be willing to implement a quick fix while everyone's waiting for nirvana. That would give users a chance to continue using digiKam, instead of migrating to other solutions.

Marcel, 

what do you think about Havart comments ?

It's fine to touch database stuff now without break something ?

Gilles

Just a reference to what I proposed on the devel mailing list...

Another bko entry, which is, imho, related to this one :
http://bugs.kde.org/show_bug.cgi?id=107871#c6


<<
I suggest to add 2 command-line options to start digikam.

* -f to to specify the full path to digikam3.db, or relative path from 
the album directory

* directory as argument => this would be the album path digikam use

Eg:

1) # digikam
would behave like now. The 1st time, it will ask for an album path

2) # digikam -f /path/to/digikam3.db
would behave like now except it will use the specific path for the 
database file

3) # digikam /path/to/my/album
digikam will use this directory as the album path, but won't override 
default album path if there's already one

4) # digikam -f /path/to/digikam3.db /path/to/my/album
would combine 2) and 3)
 >>

This would not only be a workaround for the nfs/samba locking problem, 
but also a way to extend digiKam's usage :
some people complain that they can only use one library which stores all 
their pictures. They'd like to have a few libraries. There are also some 
  people who'd like to access pictures on a read-only media (eg DVD). 
Finally, some people would also like to open a specific directory which 
contains pictures, like you can do with other tools.
All these wishes could be mostly solved by this addon...

The technical problem is that we need to pass the information to the ioslave, in the URL. We could use query items for this, and drop the usage of the "user" field as today.

*** Bug 144724 has been marked as a duplicate of this bug. ***

SVN commit 732444 by cgilles:

digiKam from trunk (KDE4) : First very important improvement here depending of the new Database interface/schema dedicaced to 0.10.0 release.

A new setting in album configuration page have been added to host the database file used by digiKam in a dedicaced place.
Before, the SQlite3 database file (digikam3.db) used by digiKam to store all image informations like Tags, Rating, Comments, Date, etc... 
been store in the root album path. This solution introduce a big problem to use a root album on a network file system like NFS, because 
SQLite3 do not like it (look here for more information : http://www.sqlite.org/faq.html#q7)

The only issue for this problem is to store the databse file in a separate place...

This is want mean than with this commit, digiKam can use a remote root album...

There is a screenshot of the new Album config page :

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

The next pending important change to do will to be able to drive more than one root album path with digiKam 0.10.0... 

CCMAIL: digikam-devel@kde.org

CCBUGS: 122516
CCBUGS: 150938
BUG: 129437
BUG: 137694



 M  +72 -58    digikam/albumsettings.cpp  
 M  +3 -0      digikam/albumsettings.h  
 M  +1 -1      digikam/digikamapp.cpp  
 M  +3 -2      digikam/welcomepageview.cpp  
 M  +72 -12    utilities/setup/setupgeneral.cpp  
 M  +5 -1      utilities/setup/setupgeneral.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=732444

Gilles,

thanks a lot for this fix - I am sure it will provide a more widespread use of digikam as it becomes available. Is there a road map for when it will be release (i.e. when 0.10.0 will be released) ? Hopefully it won't be too far into the future...and then I hope it won't take too long for 0.10.0 to trickle down into the distros...

Havard,

Release plan is on the web project page : 

http://www.digikam.org/?q=about/releaseplan

Gilles