Project

General

Profile

Bug #11314

darktable-cli should not lock the database

Added by Pascal Obry over 3 years ago. Updated 7 months ago.

Status:
Fixed
Priority:
Low
Category:
-
Target version:
Start date:
11/14/2016
Due date:
% Done:

100%

Estimated time:
Affected Version:
git master branch
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

As discussed on the dev mailing-list.

To reproduce:

1. Launch darktable
2. on a console try to export an image:

   $ darktabl-cli img.raw img.raw.xmp img.tif

The output is:

[init] the database lock file contains a pid that seems to be alive in your system: 2000
[init] database is locked, probably another process is already using it
trying to open the images in the running instance

Associated revisions

Revision be03cc54 (diff)
Added by Tobias Ellinghaus over 3 years ago

Use :memory: data db in dt-cli and generate-cache

This fixes #11314.

History

#1 Updated by Roman Lebedev over 3 years ago

That got broken when library.db was split into 2.
Now cli tries to lock data.db for some reason.

#2 Updated by Roman Lebedev over 3 years ago

  • Target version set to 2.2.0

#3 Updated by Tobias Ellinghaus over 3 years ago

  • System changed from Debian to all
  • % Done changed from 0 to 20
  • Assignee set to Tobias Ellinghaus
  • Status changed from New to Triaged

Ok, how do we want to have the system working? I never thought about anyone using dt-cli in parallel to dt running so I didn't test this. Instead of adding another command line parameter I would suggest a new flag for dt_init() that specifies to use a :memory: data.db. Or are there use cases where we want to have access to the data.db content when running from dt-cli?

#4 Updated by Pascal Obry over 3 years ago

If we run with --luacmd option I suppose everything is possible, no?

Also, the section 9.1.9 (https://www.darktable.org/usermanual/ch09.html.php) may need update too as there is no provision for a setting up a :memory: data.db.

#5 Updated by Tobias Ellinghaus over 3 years ago

Yes, using dt-cli to run Lua commands might be hard to deal with. The problem is, we can either have data.db be loaded and lock it, or not load it. Loading the database and not locking it is a VERY bad idea.
The lack of a switch for a :memory: data.db is on purpose and won't be added. data.db is part of dt's config and tied to the configdir. We also don't have a switch to point to a different keyboardrc, darktablerc or luarc.

#6 Updated by Roman Lebedev over 3 years ago

Does data.db add any functionality to dt-cli?
I would guess a default presets may be applied from data.db to the images without XMP?

#7 Updated by Tobias Ellinghaus over 3 years ago

Good point, I suppose that could happen.

#8 Updated by Tobias Ellinghaus over 3 years ago

  • % Done changed from 20 to 100
  • Status changed from Triaged to Fixed

#9 Updated by James Snyder 7 months ago

Roman Lebedev wrote:

Does data.db add any functionality to dt-cli?
I would guess a default presets may be applied from data.db to the images without XMP essay typer?

*It is interesting to enter a certain functionality into “regular” PHP files, but as long as the standard mysql_query or manual PDO connection is enough to work with the database. It is more efficient to use some things from Yii right away, for example Yii :: app () -> db or your own models. *

Also available in: Atom PDF

Go to top