Database Maintenance

I have other applications which have a project folder and projects files which are movable and stil can be opend as long as the source files it needs to reach arn’t moved or changed in name.
This is better then a closed system that can be crashing.

I wonder how they manage the many-to-many relationships, unless they are not bothered about speed

It’s inherent, tho not obvious. What it means is that as long as one keeps the sidecar/.dop file associated with each image source file then the database is effectively redundant (except that sidecar files do not retain keywords or correction history - neither of which I care about).

In fact, I use a self-written “wrapper” that deletes both the cache and the database file(s) each time before I invoke PhotoLab. Note: I am able to delete the cache because I use a “work-in-progress” approach, rather than expect PL to deal with a folder containing 100s/1000s of images (as some do).

John M

For those who don’t care about the database, history etc:
The Fundamental Settings of my previous post address just that. And you can still delete whatever you like anyway.

What we’re trying here, ist to advance DPL to be a more comprehensive Photo solution. If and how DxO will go that way will be decided by DxO. Cannot sell an annual update without more or better features :wink:

1 Like

I have mentioned, a while ago, the idea of a “plug-in” architecture, where all these “bits” could be developed and maintained without encumbering the development of the main app - a bit like FP and VP are at the moment.

What’s the feeling on this?

1 Like

Yes, I fully support that approach, Platypus - - provided it remains possible to depend only on the sidecar/.dop files … that is, provided any changes do NOT make the database an operational dependency.

John

1 Like

I personally ignore the database and rely on dop files. I would like to see keywords AND star ratings written to xmp files for interoperability with other xmp based applications.

I would, however like to have a way of viewing which directories have been added to the database and then be able to remove selected directories when they are no longer required. This would help keep the database manageable in size and speed.

4 Likes

Hi @KeithRJ,
Did you already take our mini survey about XMP and metadata?

Thanks.
Steven.

1 Like

I just did it

It would be nice to differentiate between RAW and JPG files.
To be able to write the keywords in an XMP file for RAW files but directly in the JPG file.
And to be able to put the keywords with the mouse on a click according to a detachable drop-down list like this one would be the best like for example XnView MP

2 Likes

Keywords and other basic metadata could be also written directly into RAW files.
I do that with another software since years without any issue.

1 Like

Which is where we need to discuss whether adding metadata like keywords to a RAW file is “destructive” or not.

I know other apps do it and it certainly makes life a lot easier when searching for files containing keywords, via the operating system, where you actually get a list of the image files and not the XMP sidecars. At least you avoid the dependency on a DAM to maintain its database.

Personally, I don’t see it as destructive, as it doesn’t touch the actual image, just the metadata. XMP files are seen as “safer” but then you still have the need to ensure that, by moving an image file, you also move its accompanying sidecars - in the case of PL, this would mean both the DOP and an XMP.

If you rely on XMP files for metadata, are you creating yet another dependency that needs maintaining, rather than just having one image file and its DOP?

Then you need to consider whether using the database to avoid a dependency on DOP files is any better or worse than using DOP files instead of the “putting all your eggs in one basket” approach of a database, which can corrupt?

Questions, questions, questions :crazy_face:

3 Likes

@StevenL, just done it. Thanks for pointing it out.

1 Like

I would simply like to see the addition of keywords to the .dop sidecar files and have the ability to ignore and not rely on or use the database at all. I believe that DxO PhotoLab is an excellent editing tool and should be able to stand alone. Not arguing with anyone just giving my opinion.

2 Likes

Why do you want to do otherwise than the “standard”, how many software can read DOP sidecars ?
And how many use XMP ?

But, for those who rely on XMP files from apps like Lightroom for their keywords, this would then mean those keywords would then be stored in two sidecar files.

Like @Franky says, this further removes PL from industry standards.

Ok, Franky xmp. My point is I don’t care about having a DxO database. Having the data in sidecars is enough.

Joanna, like I just replied to Franky I really don’t care if it is xmp or dop, My point is that I just don’t care about the database being a part of PhotoLab.

2 Likes

Yes me too but with sidecar data readable by other software and of course vice versa.
And don’t make it incompatible with others…

1 Like

But then how do you maintain Projects? I guess you don’t use those either but for those who do, they cannot be ignored

Joanna, I simply stated MY OPINION. I was speaking for myself and how I use the product. And, no I don’t use Projects.