DB Thumbnails

[JohnFredC]

I am out of town typing on my tablet, so not feeling overly verbose today...

But may I encourage more discussion of the semantic structure of the data and how it interacts with the physical structure in "real" world cases.

For instance, there is little reference in this fascinating thread about update performance. Searching is only one aspect of use.

Also, the easy portability of a subset of the data to other XnView installations is of high importance to many of us. Simply put, I want to copy a folder to a remote XnView system and have all the metadata travel with the folder and be available at the destination. This use case suggests that, for best performance, the metadata should be housed locally (one cache per folder).

I never need to search through all 30,000 images stored in my XnView.db. Never! So an implementation focused on such large scale queries alone would likely not benefit my use!

[oops66]

... This use case suggests that, for best performance, the metadata should be housed locally (one cache per folder). ...!

Hello JohnFredC,
... You mean: "one cache per root folder" (from the root folders list - see previous graphic) instead "one cache per folder" ?

[JohnFredC]

... This use case suggests that, for best performance, the metadata should be housed locally (one cache per folder). ...!

Hello JohnFredC,
... You mean: "one cache per root folder" (from the root folders list - see previous graphic) instead "one cache per folder" ?

No, I meant "one cache per folder".

There is a continuum between fully centralized storage and fully distributed storage. I am offering a usage case for the latter.

The question is, where on that continuum does each use case lie and why? In an ideal world a system should support both extremes as well as those "in the middle", with the user able to select from differing trade-offs (storage size, speed of access, speed of update, portability, ease of use, et al) according to their needs.

The problem is much larger than how to make "whole body" searches as quickly as possible. As I said above, I never perform such searches. But I transfer single folders between machines relatively frequently.

[oops66]

...There is a continuum between fully centralized storage and fully distributed storage...

Yes, but in fact, here, there is a compromise between these two "opposites" solutions (centralized Vs distributed).

... Because, with "one cache per root folder" (from a root folders list) you also can have "one cache per folder" if a customized action is done (by putting/filling automatically all folders into this root folders list via an xnviewmp option for this distributed db behavior)

[m.Th.]

Simply put, I want to copy a folder to a remote XnView system and have all the metadata travel with the folder and be available at the destination.

There is already such a thing for you. And it is standard: It is called XMP files (sidecars). Istm that XnViewMP outputs such things. Go to Tools | Settings | XMP & IPTC and check all the 'Export XMP...' checkboxes from there.

Ok, in order to be perfect, XnViewMP must have a checkbox saying 'Copy/Move sidecar files also'. But I cannot find it... (imho, it should be in Settings | General)

Perhaps Pierre will enlighten us.

[JohnFredC]

Apples and oranges.

IMO XMP files are for inter-application data sharing and impractical for almost all other purposes. That is why we explicitly import and export XMP data.

The discussion here is about cache implementations for XnView internal uses. I consider two XnView installations, even if separated by great distance, to be nevertheless still within my XnView domain. A user shouldn't have to perform an export/import activity to communicate a few images and their metadata (including categorizations unique to the user's XnView environment) between the two systems.

So the case of easy portability between XnView installations is where the distributed metadata paradigm fully applies. There are others.

Put the burden on the computer, not the user. I would prefer the redundancy of both centralized and distributed storage simultaneously maintained by XnView. Disk storage is much less expensive than my time and the proliferation of many small files with well-defined purposes has never concerned me.

[XnTriq]

Screenshots of the newly implemented settings (XnViewMP v0.60):

• 

• 
  [ z00m ]