Problem merging metadata

[Terisa de morgan]

Hi,

I've been looking for this issue, but i have found nothing about it.

I have a problem when I'm merging two records when there're some difference in the metadata info. If I merge two fields which are date or number, if the destination field has a value, it keeps untouched. If I merge two fields which are defined as text with restricted values, however, if the destination field has a value, and the origin field is empty, the value in the destination filed is removed.

I don't know if it's normal, I'm doing something wrong. Any help will be welcome. BTW, it's not related to calibre 2.X, it worked in the same way before.

I have Win7 and I am running calibre 32bits (calibre 64 works the same too, I've tested it).

Thanks in advance.

[Adoby]

Could be that for fields with restricted values there is no empty value. So the new value always overwrite the old, the logic that empty values don't overwrite existing doesn't apply. And I don't know how that should be changed to ensure that the "right" metadata is used. The only way around would be to be careful about using restricted values...

[chaley]

Originally Posted by Terisa de morgan

Hi,

I've been looking for this issue, but i have found nothing about it.

I have a problem when I'm merging two records when there're some difference in the metadata info. If I merge two fields which are date or number, if the destination field has a value, it keeps untouched. If I merge two fields which are defined as text with restricted values, however, if the destination field has a value, and the origin field is empty, the value in the destination filed is removed.

I don't know if it's normal, I'm doing something wrong. Any help will be welcome. BTW, it's not related to calibre 2.X, it worked in the same way before.

I have Win7 and I am running calibre 32bits (calibre 64 works the same too, I've tested it).

Thanks in advance.

The problem comes from how selections work.

If you select using the shift key (click on a book, press shift, click on another book), the selection is ordered from top to bottom no matter which book you clicked on first. Thus even if you clicked on the second in the list then the first, the second is being merged into the first as if you had clicked on the first then the second.

If you select using the control key then Qt remembers the order. Click on the second in the list then ctrl-click on the first, after which the first will be merged into the second.

I tested this as follows:

1. Create an empty book. Give it a title "Book 1" and an author "Author 1"
2. Create another empty book. Give it a title "Book 2" and an author "Author 2"
3. Sort the display by title. Book 1 will be above book 2.

Experiment 1

1. Edit metadata for Book 1. Assign a value to an Enumerated (fixed set of values) column.
2. Click on Book 1.
3. Shift-click on Book 2.
4. Alt-M to merge without deletion.

The enum value in book 1 is gone, replaced by the empty value in book 2. This is as it should be, because the target book is Book 1.

Experiment 2

1. Edit metadata for Book 1. Assign a value to an Enumerated (fixed set of values) column.
2. Click on Book 2.
3. Shift-click on Book 1.
4. Alt-M to merge without deletion.

Again, the enum value in book 1 is gone. This is because even though you clicked on book 2 first, Qt reports that the first book in the selection is book 1, so calibre merges Book 2 into Book 1 just as in experiment 1.

Experiment 3

1. Edit metadata for Book 1. Assign a value to an Enumerated (fixed set of values) column.
2. Click on Book 2.
3. Ctrl-click on Book 2.
4. Alt-M to merge without deletion.

This time the enum value from book 1 is copied into book 2 because Qt reports that the first selection is Book 2, making that book the target.

Bottom line: if you use shift-click to select, the target book must be the first one (highest one) in the selection list. This is true no matter what order you used to select the books.

[theducks]

chaley
That explains what I have been seeing for quite a while

Can Kovid include a Warning box (with a don't show again box) to remind folk to sort the target to the top, When the 'M' feature is used?

[kovidgoyal]

There is such a warning already, it even shows you the title of the book that will be the target book.

[theducks]

Originally Posted by kovidgoyal

There is such a warning already, it even shows you the title of the book that will be the target book.

I must have done away with it so long ago
or my 'I have seen that before filter' let it slip by

[Terisa de morgan]

Chaley, I understand what you say, I'm quite aware of this way of working. What I get of your message is that it's right to empty the destination field, although it doesn't work the same for integer or date fields (I always order the book so the destination book is the first in that order).

Perhaps @adoby is right, and that is the problem. I don't know.

[chaley]

Originally Posted by Terisa de morgan

Chaley, I understand what you say, I'm quite aware of this way of working. What I get of your message is that it's right to empty the destination field, although it doesn't work the same for integer or date fields (I always order the book so the destination book is the first in that order).

Perhaps @adoby is right, and that is the problem. I don't know.

No, he isn't. Enumerated types have a null (undefined) value.

I just looked more carefully at the merge code. This is a bug. The "if statement" that handles enumerations is not parenthesized correctly, resulting in the source *always* replacing the destination even if the src is empty. I will submit a fix.

[Terisa de morgan]

Thank you very much, chaley. As this is something I do for all my read books, it was a bit PIA.

[BetterRed]

FWIW - I Mark the books I want merge and then Show marked books, it makes it easier to wrangle the target book to the top of the list.

BR

[chaley]

Originally Posted by Terisa de morgan

Thank you very much, chaley. As this is something I do for all my read books, it was a bit PIA.

The fix is in place, available now if you run from source otherwise in the next calibre release.

[Terisa de morgan]

Originally Posted by chaley

The fix is in place, available now if you run from source otherwise in the next calibre release.

Thank you very much. It will be in the next calibre release, I compile a lot at work, so I'm a bit lazy at home