Displaying arbitrary results in search screen from plugin

[kovidgoyal]

search_mark?

[kiwidude]

Yeah, full circle back to my first post in the thread.

The more I think about this the more I think highlighting is not the right approach for this plugin. The problem is that I am trying to highlight rows which need attention by the user. If they use the likes of the bulk metadata edit dialog to edit only a subset of the rows, they are going to lose their highlighted rows and have to run the plugin action again to see the rest. Plus either I select all the invalid rows for them which gives them no individual review or I only select the first which makes it a pain for them to select the rest.

The custom column approach has some challenges of its own but perhaps is a bit more flexible/robust in this situation.

EDIT: While I was typing you guys have come up with what sounds a nice solution to the "challenges" I had in mind... very cool.

[chaley]

Major problem. The virtual column will not survive cache.refresh() because there is no data source.

This can be fixed at the cost of having refresh() call a function that checks for the presence of an ID in a set. Are we willing to pay that price?

[kovidgoyal]

Since the set will typically be empty, seems like it shouldn't be much overhead.

[kovidgoyal]

Since the set will typically be empty, seems like it shouldn't be much overhead. We can optimize the case of an empty set so that it is only a single if statement per refresh call.

[kovidgoyal]

In fact, if you are storing the ids in the set, then you dont actually need to test each id, instead iterate over the ids in the set and set the flag on each row manually, which is an O(1) operation per id

And I think "marked" is a better search term than "search_mark"

[chaley]

Originally Posted by kovidgoyal

Since the set will typically be empty, seems like it shouldn't be much overhead. We can optimize the case of an empty set so that it is only a single if statement per refresh call.

So, this is a boolean column, tested for presence in a set. That means that the user cannot provide different values, permitting sorting, subsearching, etc. OK with everyone? If not, then I need provide a dict interface, where the caller gives me {id:val,...}

As for the empty set, I am not convinced that an 'if foo: xxx' is much faster than 'if id in some_empty_set'.

[kiwidude]

For my own needs for this plugin a boolean column is fine. The mythical duplicate finder plugin will need a dedicated custom column and will likely want to be persisted across Calibre restarts. That's the only uses I personally have fwiw.

[kovidgoyal]

Fine by me.

[chaley]

After thought, I was bothered a bit by purposely limiting the value to bool, especially as it gains no performance. Looking up a key in a dict has the same performance as looking up a key in a set. Both are hashed in the same way.

What I am ready to commit:

Setting API:
db.set_marked_ids(ids) -- ids can be a list or dict. If a list, then a dict is constructed where {id:'true'} for all ids in the list. If it is a dict, then it is copied and checked to be sure that all the values are unicode.

If ids == [] or {}, the right thing happens.

The virtual column is set to the val if id is in the dict, otherwise None.

Search API:
marked:true -- finds anything set. If a list was passed to set_marked_ids, then it finds all the ids in that list.

marked:false -- finds anything not set.

marked:foobar -- if a dict was used, then this will find any book with value foobar. All the string matching search syntax can be used (equals, contains, regexp).

Usage:
1) call db.set_marked_ids(...).
2) call gui.search_box.set_search_string('marked:...') where the ... is what you want.

The user can, of course, make a saved search and then use that search as a restriction. There is no API to do these things.

[kovidgoyal]

Sounds fine

[kiwidude]

Originally Posted by chaley

If ids == [] or {}, the right thing happens.

By "right thing" do you mean it clears all marked ids?

[chaley]

Changes are now in trunk.

[chaley]

Originally Posted by kiwidude

By "right thing" do you mean it clears all marked ids?

Correct

[kiwidude]

Working brilliantly, plugin now finished for a release this weekend. Thanks for the additions.