Bug 183972

Summary:	"Album Path" config variable still necessary?
Product:	[Applications] digikam	Reporter:	Andi Clemens <andi.clemens>
Component:	Setup-Database	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	caulier.gilles, marcel.wiesweg
Priority:	NOR
Version:	0.10.0
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:	1.0.0
Sentry Crash Report:

Description Andi Clemens 2009-02-11 00:31:27 UTC

Version: 0.10.0-rc2 (using 4.2.00 (KDE 4.2.0), Arch Linux)
Compiler: gcc
OS: Linux (i686) release 2.6.28-ARCH

I have changed the database location path in the setup dialog to the place where my old digikam3.db lives in, because I wanted to test the converting of the database.
I was asked to either create a new database or copy the currently used one.
After clicking on "Create new database", the database was converted and the AlbumUI was shown again. But there was a very strange root folder now:

/home/andi/.testfotos

This folder doesn't even exist anymore, I had used it months ago as my digikam testcollection. My current test-collection lies in here (the one I used before converting the digikam3 database):

/mnt/data/testcollection/

This means the "Album Path" variable in the config file was only created during the first digiKam run and never changed again. But it is used to set collection root path when converting the database from digikam3.

If I take a look at the variable now, after changing to the correct root path where my digikam3.db lives in, the config variable has still not been updated.

Do we really need this? It leads to very strange results when changing to new database locations (or even creating new ones).

I expect digiKam to do the following:

- When changing to a path where an old digikam db is found and you click "create new database", it should convert the db file and set the collection root to the location of the database

- do not use "Album Path" variable at all, it has no purpose anymore

Comment 1 Marcel Wiesweg 2009-02-11 18:51:03 UTC

The config entry is used in schemaupdater when updating from 0.9, that cannot have hit you here (unless there was an old digikam3.db lying in that folder)
Then it is used in main.cpp, when no collection is found and also when the first run dialog is run (should use a better interface to the dialog's result, that's for sure). 
All that would be resolved if an initial collection was added when starting with a fresh db.
I think we had a complex discussion by mail about that, which I dont remember in detail, but thinking about it I dont believe the issues were properly resolved.

Comment 2 Marcel Wiesweg 2009-02-22 18:18:03 UTC

SVN commit 930090 by mwiesweg:

Expose chosen settings in API, so config need not be accessed to get result

CCBUG: 183972

 M  +15 -1     digikamfirstrun.cpp  
 M  +3 -0      digikamfirstrun.h  


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

Comment 3 Marcel Wiesweg 2009-02-22 18:18:13 UTC

SVN commit 930091 by mwiesweg:

In setDatabase, check that there is at least one album root.
If called after the first-run dialog from main, a suggestion is given.
Otherwise (creating a fresh db from changeDatabase()) the setup collections page is opened.

CCBUG: 183972

 M  +14 -1     albummanager.cpp  
 M  +1 -1      albummanager.h  


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

Comment 4 Marcel Wiesweg 2009-02-22 18:18:20 UTC

SVN commit 930093 by mwiesweg:

- use "Album Path" when upgrading from 0.9 to read database location
- get chosen values directly from FirstRun dialog
- properly delete first run dialog
- leave check that at least one album root exists to AlbumManager

CCBUG: 183972

 M  +10 -18    main.cpp  


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

Comment 5 Marcel Wiesweg 2009-02-22 18:18:27 UTC

SVN commit 930094 by mwiesweg:

Add code for use case of moving db dir to a directory with an old 0.9 database file.
Try to consolidate monster method.
This needs testing.

CCBUG: 183972

 M  +89 -37    albummanager.cpp  


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

Comment 6 Marcel Wiesweg 2009-06-29 22:51:23 UTC

Andi, can we close this bug or is there a situation that still fails?

Comment 7 Marcel Wiesweg 2009-06-29 22:54:07 UTC

Btw, I tried removing the config variable but came to situations where upgrading failed, and decided not to invest too much into this or run the risk of breaking well-tested scenarios.

Comment 8 Andi Clemens 2009-06-29 23:00:23 UTC

Good question, I have not tested this in a while. I think we can close it since it was a special case of testing (and I guess it was even fixed as I tested it after your above commits).

Andi

Comment 9 Andi Clemens 2009-10-08 01:18:20 UTC

I close this one as WONTFIX, it is not that important and before it creates more trouble than it solves any... :-)