[GUI Plugin] Action Chains

[capink]

@chaley: First, thanks for your time and effort.

I tested your changes, and so far they are working well. I ran your test as well as some other tests related to Last Modified Plugin and all is working as expected. Signals are are only released for fields for whose the value is altered.

How do you think this will impact calibre's performance?

[chaley]

Originally Posted by capink

How do you think this will impact calibre's performance?

It could go either way. Setting a field to its current value will be significantly faster because it isn't dirtied (queued for metadata backup), the last_modified isn't set, and in several cases a database update is avoided.

If a field is really being changed: many-to-many fields like tags won't see a hit because they already did the optimisation. Other fields now have a bit more processing to check if the value is being changed. In some cases a field was being updated twice (e.g., custom series indices), which is no longer happening.



I will make a pull request and see what Kovid thinks.

[BetterRed]

Originally Posted by chaley

It could go either way. Setting a field to its current value will be significantly faster because it isn't dirtied (queued for metadata backup), the last_modified isn't set, and in several cases a database update is avoided.

As you may recall, I do 99% of metadata edits in in the Book List. After tapping F2 on the first cell I want to change, I use Tab to move across the cells whilst remaining in edit mode; and I often Tab through cells, leaving them as-is or empty as the case may be.

Will this change have any effect on that mode of use, if anything it appears it might improve performance.

I don't use the AC or LM plugins.

BR

[chaley]

Originally Posted by BetterRed

As you may recall, I do 99% of metadata edits in in the Book List. After tapping F2 on the first cell I want to change, I use Tab to move across the cells whilst remaining in edit mode; and I often Tab through cells, leaving them as-is or empty as the case may be.

Will this change have any effect on that mode of use, if anything it appears it might improve performance.

These changes won't affect this "mode of use" in any significant way. It takes much longer to process hitting Tab and update the GUI than to check if the field changed. In addition I think that the editors already check if something changed, in which case you will see no change at all.

[capink]

Originally Posted by chaley

In addition I think that the editors already check if something changed, in which case you will see no change at all.

I think not. You can verify that by pressing F2 followed by enter without changing the value, and then checking the last_modified value. That changes made by chaley will ensure this will not happen.

[BetterRed]

@chaley - tks

can I draw you attention to the last post in this thread ==>> https://www.mobileread.com/forums/sh...d.php?t=341670

cheers BR

[chaley]

Originally Posted by capink

I think not. You can verify that by pressing F2 followed by enter without changing the value, and then checking the last_modified value. That changes made by chaley will ensure this will not happen.

It depends on the field. I tried it with Authors, Title, an enumerated column, and an integer column. Edit/return on the Authors and the enum column didn't change last_modified. The other two did.

These results doesn't negate what you said, that the editors don't do the check. I think the difference is that many-many columns already have the check in the db layer.

[BetterRed]

Originally Posted by capink

I think not. You can verify that by pressing F2 followed by enter without changing the value, and then checking the last_modified value. That changes made by chaley will ensure this will not happen.

That's what I thought.

If I do as you suggest the Last Modified date changes to Now and the disk rattles as a fresh metadata.opf is written to the book folder on every cell I tab through whilst in Edit mode.

The slight performance hit doesn't bother me. I find editing in the list much easier, hence faster than editing in dialogue boxes.

Added: I think we're all agreed these changes shouldn't have any deleterious effect on editing metadata on the book List, if anything the opposite. If KG accepts @chaley's changes I'll make of point of letting y'all know.

BR

[chaley]

Originally Posted by BetterRed

Added: I think we're all agreed these changes shouldn't have any deleterious effect on editing metadata on the book List, if anything the opposite. If KG accepts @chaley's changes I'll make of point of letting y'all know.

BR

The changes are now in master source.

[capink]

@chaley: Thanks again. You help has been, as always, invaluable.

[capink]

Originally Posted by ownedbycats

Question: I have several cleanup chains that modify multiple columns in a row. Unfortunately Last Modified seems to trigger for all of them which causes a slight pause between each action; running the chain with my column turned off sped things up considerably.

Is there a way to alleviate this, such as making it trigger only on the last change?

I think I have a solution for this now. I will add a hibernation mode for the Last Modified plugin, which can be activated by other plugins. During this hibernation period, the plugin will listen to and cache db events without taking any action. After getting out of the hibernation mode, it will re-emit one db event per field (for all books) to enhance performance.

This will need modifications to both Last Modified and Action Chains, and will only be released after the release of the next version of calibre.

[capink]

Originally Posted by capink

I think I have a solution for this now. I will add a hibernation mode for the Last Modified plugin, which can be activated by other plugins. During this hibernation period, the plugin will listen to and cache db events without taking any action. After getting out of the hibernation mode, it will re-emit one db event per field (for all books) to enhance performance.

This will need modifications to both Last Modified and Action Chains, and will only be released after the release of the next version of calibre.

@chaley: How can I incorporate the advice below with set_field()

Originally Posted by chaley

But with auto-commit turned off so the transactions are grouped into one commit.

[chaley]

Originally Posted by capink

@chaley: How can I incorporate the advice below with set_field()

I don't think you can. cache.set_metadata() does it by wrapping the set_field()s in a "with db" connection. You don't have that option.

The best approach would be to gather together all the changes to a field and apply them with one set_field. Something like a caching single_field_edit action that is paired with a commit action. This might introduce timing problems though.

[capink]

The commit question was about optimizing performance when calling set_field() for multiple fields (date fields by Last Modified), but it is not a big deal. Thanks.

[ownedbycats]

Btw, since I can run from source I am willing to do some testing.