[digikam] [Bug 377587] New: The --database-directory argument should also be the location of the digikamrc file when used

[bugzilla_noreply]

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

            Bug ID: 377587
           Summary: The --database-directory argument should also be the
                    location of the digikamrc file when used
           Product: digikam
           Version: 5.4.0
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: Database-Setup
          Assignee: [hidden email]
          Reporter: [hidden email]
  Target Milestone: ---

The intent of the --database-directory command line option is to allow for
multiple independent DK databases and instances.  However the current usage of
the application wide config file, digikamrc, is at odds with this.  The
digikamrc file can not be specified on the command line, so there is only one
per user, even though there may be multiple digikam databases.  Since the
digikamrc file has some settings that definitely should be different per
digikam database instance, such as the "Database Settings", there should be a
way to specify a different digikamrc file when selecting a non-default database
instance.

I suggest that the directory specified via --database-directory be the
directory where the digikamrc file is expected.

This would be a very simple to fix by modifying the KSharedConfig construction
at https://cgit.kde.org/digikam.git/tree/app/main/main.cpp#n150.  If
commandLineDBPath is null do what is done now, otherwise do construct like:
KSharedConfig::openConfig(commandLineDBPath + QLatin1String('/digikamrc'))

This will make digikam instances truely independent and should have the added
benefit of fixing bug 218297 as well.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #1 from Simon <[hidden email]> ---
Git commit e0f1d3dd4056deff260f673788af2cc6f9df1033 by Simon Frei.
Committed on 18/03/2017 at 15:00.
Pushed by sfrei into branch 'master'.

Add --config option and fix --database-directory option

When database dir is specified at command line, the correct path is displayed
in the configuration widget, but the input field is disabled.
Related: bug 218297
FIXED-IN: 5.6.0

M  +2    -1    NEWS
M  +39   -4    app/main/main.cpp
M  +2    -2    libs/database/utils/dbmigrationdlg.cpp
M  +10   -1    libs/database/utils/dbsettingswidget.cpp
M  +2    -1    libs/database/utils/dbsettingswidget.h
M  +3    -0    libs/settings/applicationsettings.h
M  +10   -0    libs/settings/applicationsettings_miscs.cpp
M  +2    -0    libs/settings/applicationsettings_p.cpp
M  +1    -0    libs/settings/applicationsettings_p.h

https://commits.kde.org/digikam/e0f1d3dd4056deff260f673788af2cc6f9df1033

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

Simon <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #2 from Simon <[hidden email]> ---
The above commit introduced the --config command line option. To set the
database dir and config file to the same path, you can specify both options.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

Glenn Washburn <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WORKSFORME                  |---

--- Comment #3 from Glenn Washburn <[hidden email]> ---
I think to fix this and provide a better user experience a small change should
be made.  The idea is that specifying --config is very likely if you are
specifying --database-directory.  So it would be nice to have a
per-database-directory config file default.  It makes sense that this would be
in the same directory as specified by the --database-directory option.

This is a pretty trivial change and I don't see any downsides.  However, there
are downsides to not changing this.  My worry is that by sharing a config file,
I might change a setting when using one DK database instance that will affect
another database instance without my being aware of it, until its too late.

Here's an scenario. Suppose I have one DK database instance, call it A,
managing a set of photos that I want the XMP metadata written into the image
and another DK database instance, call it B, where I want them written as
sidecar files only.  Since I'm a photographer and not a DK developer, I don't
know how DK configs are stored.  I might even guess wrongly, that they are
stored in the digikam4.db file.  So I don't realize that to not shoot myself in
the foot, I need to have two separate config files.  By default, the default
config will be shared (bad default in this case).  So supposing I setup
instance B first, then A, then when I start adding tags to B, the photos in B
will be modified, not what I was expecting.

I suspect there are a lot of use cases like the above for different config
settings.  It seems to me that the best course of action would be to default to
unique default config file when using --database-directory.  There should be no
fallback to the global default config file when --database-directory is given.
If the user really wants to use a different config file path, perhaps sharing
with another DK instance, they can do so explicitly.  Bottom line: sharing
config files is dangerous and should not be default behavior.

The logic should be that if no --config is given, DK should first check for
digikamrc in the directory specified by --database-directory, and if it does
not exist should create a new one with default values.

This would get DK another step closer to having photo collections that are
easily re-locatable.  I'm changing this back to "UNCONFIRMED" because I don't
think this issue was really resolved.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #4 from Simon <[hidden email]> ---
Ok I see your point and I completely agree, this is not an issue of
implementing, but of what behaviour do we really want. I am happy to change it
once we reach a consensus.

I will explain my point of view, but I am aware that it may be skewed due to
"knowing the inner workings":
In my opinion the behaviour should always be the least surprising. We have both
--database-directory and --config (I assume that anyone who actually uses
command line arguments is aware of this). For me the simplest and clearest is,
when both have just one purpose. With your proposal --database-directory has
the side effect of also changing the config location, which is (still, my
impression) not directly obvious. Database and configuration being separate
entities is common for many software.

My intended use case: I have two collections, one on the laptop and on a
network share. The databases are also stored on the laptop and on the network
share respectively. I want digikam to have the same behaviour no matter which
database I am using, so I share the config between the two.

About your use case: Information is always stored in the database. You can only
select whether you want to store it in image metadata/sidecar files as well.
Therefore I don't really understand your example, unless A and B manage the
same set of photos in the same location. But that would mean having different
information in the image metadata and the sidecar in the same location, which
seems very wrong to me in the first place (?).

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #5 from Glenn Washburn <[hidden email]> ---
In my example I was making use of the checkbox config option labeled "Write to
sidecar files" in the Metadata pane of the configuration dialog.  Once
selected, a select box become enabled, where one of the options is labeled
"Write to image and to XMP Sidecar".  This option will modify the data of image
files.  So my constructed scenario was over two disjoint image sets, one where
you want the image data modified and one where you didn't.  I was attempting to
show how using a shared config you could get into a situation where you end up
modifying the image data in the image set that you did not want to modify
because you had changed the setting in DK while using the other dataset.  If
you are unaware that that config is stored in the shared config file, as
opposed to the database, you might not realize that it had been changed for the
other image set that shared that config file.  Basically it would appear as
though someone had changed that setting without your knowledge and you might
not discover this until DK had started to write to your images.  And if that's
your only set of image (bad practice, but I doubt that uncommon), then you've
just irreversibly modified your originals.  I hope that makes it a little more
clear.

I take your point about the non-obviousness of my suggestion, and I agree that
generally options should not modify other options.  It can be confusing.  I
think to help alleviate that a short sentence in the --database-directory help
text could say something like "This option changes the default config to be in
the given directory."

I think what makes this issue critical is that DK can modify your data without
you realizing it because of a non-obvious sequence of events.  I'm concerned
with anything that might modify the database or image files in a way that the
user was not-expecting and which can not easily be reversed.  My example was a
case where the images were modified, but I believe there's a case for modifying
the database when using the Maintenance tool and syncing the image metadata to
the database.  It could be overwriting data you didn't intend if you're not
checking the Metadata settings every time (because say you don't think you need
to because you didn't change it in this instance).

After looking at the config options a little more, I don't think there's a lot
of areas where this problem exists.  Its mostly related to the the Metadata
pane.  For most of the settings, its not so consequential if the value changes
without the users knowledge.

I think my suggestion is the most conservative one to take.  If the user gets
annoyed that they have to change the same config option for each DK database
instance, they'll look into using a shared config.  Its annoying and extra time
spent, but I think that's better than potential data loss.

As to your example, I think its a very valid use case.  I just don't think it
should be the default.

Also, considering that users of the --database-directory option will have been
using the user global config file.  It might make sense to copy that file (if
it exists) to the --database-directory, and then use it.  This will effectively
break the shared config behavior that currently exists, but will minimize the
impact by keeping the expected the config values.

Since, we've had the shared config be the behavior when using
--database-directory since its implementation (I presume), I wonder if anyone
has been hit by this?  But we likely would not even know this was the issue
because the user might just think this is DK corrupting things.

--
You are receiving this mail because:
You are the assignee for the bug.

[Simon Frei]

Thanks for the clarification, I get your scenario now. So it is a
trade-off between no side-effects and data safety. I still think that a
user using the command line options should be aware of the difference
between config and database and therefore be in charge of using
sensible/safe options. However planning for the DAU is also a good idea.

I would like to hear what Gilles/Maik/Mario/... think about this.
Recap: The question is which of these options is favourable (arguments
in the comments above):
1. Set config to the same directory as --database-directory. If no
config file exists there, create a new one/copy over the default one
(still respecting --config if given).
2. Always use the default config unless --config is given, also with
--database-directory.

[Andrew Goodbody]

My vote is for 2) - always do what you're told and only what you're
told. Give as much control to the user as possible, do not do unexpected
things. Using a different config and/or creating a new one is very
unexpected. I see no reason to assume the config would be colocated with
the database, that's a very strange idea.

Andrew

On 23/03/17 11:48, Simon Frei wrote:

> Thanks for the clarification, I get your scenario now. So it is a
> trade-off between no side-effects and data safety. I still think that a
> user using the command line options should be aware of the difference
> between config and database and therefore be in charge of using
> sensible/safe options. However planning for the DAU is also a good idea.
>
> I would like to hear what Gilles/Maik/Mario/... think about this.
> Recap: The question is which of these options is favourable (arguments
> in the comments above):
> 1. Set config to the same directory as --database-directory. If no
> config file exists there, create a new one/copy over the default one
> (still respecting --config if given).
> 2. Always use the default config unless --config is given, also with
> --database-directory.
>
>

[Gilles Caulier-4]

Simon,

I agree with Andrew. Point 2/ is more logic in this scénario.

Note : Why this story is not fully in bugzilla file ? Somebody has responded directly by mail to the bugzilla notification and the file is not updated as 377587 comments... 

I recommend to backport missing comments in bugzilla to not lost full story. 

Gilles

2017-03-24 1:00 GMT+01:00 Andrew Goodbody <[hidden email]>:

My vote is for 2) - always do what you're told and only what you're told. Give as much control to the user as possible, do not do unexpected things. Using a different config and/or creating a new one is very unexpected. I see no reason to assume the config would be colocated with the database, that's a very strange idea.

Andrew

On 23/03/17 11:48, Simon Frei wrote:

Thanks for the clarification, I get your scenario now. So it is a
trade-off between no side-effects and data safety. I still think that a
user using the command line options should be aware of the difference
between config and database and therefore be in charge of using
sensible/safe options. However planning for the DAU is also a good idea.

I would like to hear what Gilles/Maik/Mario/... think about this.
Recap: The question is which of these options is favourable (arguments
in the comments above):
1. Set config to the same directory as --database-directory. If no
config file exists there, create a new one/copy over the default one
(still respecting --config if given).
2. Always use the default config unless --config is given, also with
--database-directory.

[bugzilla_noreply]

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

--- Comment #6 from Simon <[hidden email]> ---
Below are three emails concerning this issue posted to the developer mailing
list. Apparently I wrote quite a few comments to bugs by email which never
reached the actual bug. Sorry if I spammed the mailing list with tries to get
it to work (I didn't).

On 24/03/17 04:32, Gilles Caulier wrote:

> Simon,
>
> I agree with Andrew. Point 2/ is more logic in this scénario.
>
> Note : Why this story is not fully in bugzilla file ? Somebody has
> responded directly by mail to the bugzilla notification and the file is not
> updated as 377587 <https://bugs.kde.org/show_bug.cgi?id=377587> comments...
>
> I recommend to backport missing comments in bugzilla to not lost full
> story.
>
> Gilles
>
>
>
> 2017-03-24 1:00 GMT+01:00 Andrew Goodbody <[hidden email]>:
>
>> My vote is for 2) - always do what you're told and only what you're told.
>> Give as much control to the user as possible, do not do unexpected things.
>> Using a different config and/or creating a new one is very unexpected. I
>> see no reason to assume the config would be colocated with the database,
>> that's a very strange idea.
>>
>> Andrew
>>
>>
>> On 23/03/17 11:48, Simon Frei wrote:
>>
>>> Thanks for the clarification, I get your scenario now. So it is a
>>> trade-off between no side-effects and data safety. I still think that a
>>> user using the command line options should be aware of the difference
>>> between config and database and therefore be in charge of using
>>> sensible/safe options. However planning for the DAU is also a good idea.
>>>
>>> I would like to hear what Gilles/Maik/Mario/... think about this.
>>> Recap: The question is which of these options is favourable (arguments
>>> in the comments above):
>>> 1. Set config to the same directory as --database-directory. If no
>>> config file exists there, create a new one/copy over the default one
>>> (still respecting --config if given).
>>> 2. Always use the default config unless --config is given, also with
>>> --database-directory.
>>>
>>>
>>>

--
You are receiving this mail because:
You are the assignee for the bug.

[Gilles Caulier-4]

No problem Simon.

I would just to inform that comments are not populated in bugzilla. For the story, all can be lost. As comments are long and constructive, i think it's important for QA.

Best

Gilles

2017-03-24 10:00 GMT+01:00 Simon <[hidden email]>:

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

--- Comment #6 from Simon <[hidden email]> ---
Below are three emails concerning this issue posted to the developer mailing
list. Apparently I wrote quite a few comments to bugs by email which never
reached the actual bug. Sorry if I spammed the mailing list with tries to get
it to work (I didn't).

On 24/03/17 04:32, Gilles Caulier wrote:
> Simon,
>
> I agree with Andrew. Point 2/ is more logic in this scénario.
>
> Note : Why this story is not fully in bugzilla file ? Somebody has
> responded directly by mail to the bugzilla notification and the file is not
> updated as 377587 <https://bugs.kde.org/show_bug.cgi?id=377587> comments...
>
> I recommend to backport missing comments in bugzilla to not lost full
> story.
>
> Gilles
>
>
>
> 2017-03-24 1:00 GMT+01:00 Andrew Goodbody <[hidden email]>:
>
>> My vote is for 2) - always do what you're told and only what you're told.
>> Give as much control to the user as possible, do not do unexpected things.
>> Using a different config and/or creating a new one is very unexpected. I
>> see no reason to assume the config would be colocated with the database,
>> that's a very strange idea.
>>
>> Andrew
>>
>>
>> On 23/03/17 11:48, Simon Frei wrote:
>>
>>> Thanks for the clarification, I get your scenario now. So it is a
>>> trade-off between no side-effects and data safety. I still think that a
>>> user using the command line options should be aware of the difference
>>> between config and database and therefore be in charge of using
>>> sensible/safe options. However planning for the DAU is also a good idea.
>>>
>>> I would like to hear what Gilles/Maik/Mario/... think about this.
>>> Recap: The question is which of these options is favourable (arguments
>>> in the comments above):
>>> 1. Set config to the same directory as --database-directory. If no
>>> config file exists there, create a new one/copy over the default one
>>> (still respecting --config if given).
>>> 2. Always use the default config unless --config is given, also with
>>> --database-directory.
>>>
>>>
>>>

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #7 from Glenn Washburn <[hidden email]> ---
You summarized it well, "a trade-off between no side-effects and data safety".
While I agree with Andrew in principle, I don't in this specific case.  I think
we're trading one unintuitivity for another and going from benign to dangerous
consequences in the process.  My suggestion would be less unintuitive if we
have a comment in the help about the side-effects, while I think it would be
harder to explain the unintuitiveness of sharing a config to the user.

There is perhaps a third way.  Take the "dangerous" settings in the config and
move them into the database.  There is already a "Settings" table where there
are some config settings (settings that could be global, though determined to
be , accurately so I think, more useful on a per database basis, eg.
"databaseImageFormats").  I don't particularly like this option because it
makes it harder to copy those settings to another database if so desired.

I think there may be a difference of vision for DK here.  I want DK to be an
app that manages sets of photos, potentially many sets, where each set is
pretty independent.  The defaults should be easy, intuitive, safe.  It feels
like DK was developed to be used as a single database instance app, which has
been hacked to allow other databases to be used.

If you're transferring your collection to another computer, you'd want your
config to go with it because it contains parameters that define how you work
with your photos collection.  I suspect most users would have to dig to even
figure out where the config file is located.  I think it makes sense to keep
the config file with the database files.  Perhaps ultimately the global config
should only store the most recently used database (eg. only "Database
Settings"), but that would probably be another bug report.

--
You are receiving this mail because:
You are the assignee for the bug.