View Single Post
Old 02-27-2011, 08:11 AM   #4
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 11,728
Karma: 6690881
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Thinking further about this, a few changes would make it possible. I am willing to make them if Kovid says 'go ahead' (something I am not convinced he will do for various reasons).

The idea is to include all the custom book data in the meta2 view. It would be done similarly to how the author sort map is done today, but returning a JSON-encoded string such as
{ "custom_data_name" : JSON_data_from_DB , custom_name_2, JSON_data_2, ...}. This string would be added to the values returned by get_metadata (mi.custom_data = row[nnn]). A template function would be provided that decodes that data, selects out a custom_data_name, then selects an attribute from that name.

An alternative to adding the information to the view is doing the necessary select in get_metadata. My problem with this approach is that we might end up doing the same select multiple times, because there is no guarantee that get_metadata is not called more than once for the same book.

This scheme has the advantage that almost no processing is required unless a) custom data exists, and b) someone uses the information.

The disadvantages that I can see are:
1) Even if there is no custom data, there would be a small performance penalty to put the None into the view. I think this penalty is very close to zero.
2) If there is custom data, then the JSON strings must be fetched and concatenated. This operation might add a few percent to the time to build the view, depending on the amount of data.
3) The template function would be rather slow, because it would decode the JSON data. It would also require that the custom data be a dict of (dicts/lists). The function would look something like "custom_data(data_name,item_name)". If the data under data_name is a list, then item_name must be an integer. If the data is a dict, then item_name must be a string.

With the above, one can create a composite custom column to show the custom data. For example, and making a large number of assumptions, the goodreads_id could be displayed using the template
Code:
program: custom_data('goodreads_plugin', 'goodreads_id')
It could become Yes/No using
Code:
program: test(custom_data('goodreads_plugin', 'goodreads_id'), 'Yes', 'No')
chaley is offline   Reply With Quote