Feature request: More flexible series

[jindroush]

Hi,
I tried to search forum for duplicate request, but didn't find it.

I'd like to see to have the ability:
a) for book to be in more than one series
b) to have the possibility not to enter series index if needed

For a) it would behave similarly to tags in mass edit dialogue, I believe division by ; would work okay. Export, import, edit, all of these would be similar, maybe with the exception of auto-setting [1], at least gui wise.
For database, it's simple N:M table for connecting book-id to series-id/index. Similar table must exist now for linking book-author records.

For b) this feature request was already here (with solutions as '0' or '1000' which are dirty workarounds, not solutions).
Also people requested ranges (for omnibuses), but these could be worked around by multiple records SeriesName #1; SeriesName #2; SeriesName #3
Also, I think the number shouldn't be float or double, but something like Integer.Integer because there are such systems around, I believe Goodreads (which I plan to synchronize to).

Goodreads example:
https://www.goodreads.com/book/show/18709246-bullseye
Book in two series, both in .5 order

[eschwartz]

1) Use a custom column of type series.
2) I like my "dirty" workaround, and I don't really understand what point you think you are making about them. What difference does it make if there is a number there you are ignoring? Surely there must be something there anyway, to indicate null -- that is what the zero was invented for, so we could express non-existence.

If you really, really want... change the default value.
Preferences ==> Advanced ==> Tweaks.
tweak value of Auto increment series index

series_index_auto_increment = '0'

And what does it being a float or not have anything to do with the price in China? For that matter, why are you so sure of what goes on in Goodreads' backend?
Series in calibre is capped at 2 decimals anyway, as if that made any difference.

[eschwartz]

And lo, the Goodreads metadata source plugin. Hmm, the author didn't seem to be troubled by the number of decimals...
https://www.mobileread.com/forums/sho...d.php?t=130638

[JSWolf]

I think what the OP wants is the series column to support multiple series like the tag column supports multiple tags.

[eschwartz]

Originally Posted by JSWolf

I think what the OP wants is the series column to support multiple series like the tag column supports multiple tags.

Hence answer #1, which I have seen Kovid give numerous times (every time someone asks for the series column to support multiple series').

And also a confusing bone to pick with floats as the datatype.

[davidfor]

Originally Posted by eschwartz

And also a confusing bone to pick with floats as the datatype.

To my mind the series index is more like a version number than a number. If I was writing "1.1", "1.12", I would probably be referring the first and twelfth story that are between the first and second novels. In calibre, I would have to record that as "1.01" and "1.12". That works if I plan ahead or know there are more than ten in-between stories, but I rarely do (plan ahead).

[eschwartz]

That is what I use it for as well. I solve the problem, BTW, by always using the smaller version. I think chaley has a calibre-debug script he created for someone to check the other same-series entries for >=10 and insert a final value into a custom column.

[aleyx]

Originally Posted by eschwartz

Hence answer #1, which I have seen Kovid give numerous times (every time someone asks for the series column to support multiple series').

That solution does store the needed data correctly, but doesn't help when you want to actually use that data (i.e. in searches, filters, templates, etc) without adding max(series_*) fields, where series_* are the custom columns added.

Several use cases come to mind, but mostly short stories collections where two or more works are side-stories in their respective series. Looking for "My Series" would look like

series:"=My Series" or series_1:"=My Series" or series_2:"=My Series" or series_3:"=My Series" or series_4:"=My Series"

That would work of course, but at the cost of legibility and maintainability. Same with column colors/icons, etc.

Originally Posted by eschwartz

And also a confusing bone to pick with floats as the datatype.

Yeah, I don't really understand either. For my part, beside the formatting point davidfor made, I'd think that Python's distutils.version would make more sense and be more flexible. But I guess perfs would take a non-negligible hit.

N.

[chaley]

Originally Posted by aleyx

That solution does store the needed data correctly, but doesn't help when you want to actually use that data (i.e. in searches, filters, templates, etc) without adding max(series_*) fields, where series_* are the custom columns added.

Several use cases come to mind, but mostly short stories collections where two or more works are side-stories in their respective series. Looking for "My Series" would look like

series:"=My Series" or series_1:"=My Series" or series_2:"=My Series" or series_3:"=My Series" or series_4:"=My Series"

That would work of course, but at the cost of legibility and maintainability. Same with column colors/icons, etc.

You can solve the searching problem using grouped search terms (preferences / searching). They let you combine multiple columns into one virtual column.

Coloring and icon rules would require a different solution, probably a tags-like composite column that aggregates the names from the columns included in the search term. Hmmm... I could make a template function that returns the values in the "virtual" column. This would be a gui-only function so it would not obviate the need for the composite column if the info is to be used in save-to-disk templates.

I am not sure what problem you are solving with the max() function.

[Terisa de morgan]

Originally Posted by jindroush

Also people requested ranges (for omnibuses), but these could be worked around by multiple records SeriesName #1; SeriesName #2; SeriesName #3

Not really, these would be a mess if I have to put "n" times the same series and all the numbers....

Originally Posted by jindroush

Also, I think the number shouldn't be float or double, but something like Integer.Integer because there are such systems around, I believe Goodreads (which I plan to synchronize to).

Please, could you elaborate about the difference between integer.integer and float. Taking into account that you can number a book as 5.55 (I've checked).

[aleyx]

Originally Posted by chaley

You can solve the searching problem using grouped search terms (preferences / searching). They let you combine multiple columns into one virtual column.

Coloring and icon rules would require a different solution, probably a tags-like composite column that aggregates the names from the columns included in the search term. Hmmm... I could make a template function that returns the values in the "virtual" column. This would be a gui-only function so it would not obviate the need for the composite column if the info is to be used in save-to-disk templates.

Which is why upgrading the original 'series' field would be the easiest solution. Well, depending on how difficult it would be to upgrade it in the first place, obviously.

Originally Posted by chaley

I am not sure what problem you are solving with the max() function.

That was just a shorthand for something like "as many fields as the number of series added to the book with the most series". I couldn't turn that phrase into something readable, so I just put max(series_*), except that now that I read it again, it's obvious I'm not using the right aggregate function. Ah well.

N.

[chaley]

Originally Posted by aleyx

Which is why upgrading the original 'series' field would be the easiest solution. Well, depending on how difficult it would be to upgrade it in the first place, obviously.

Kovid has said many times that changing the original series column to contain some sort of multiple series/range will not happen. FWIW: having worked in that code at length, I agree with his position. Such a change would be a massive undertaking.

Given this fact, we are left with finding ways for people to solve the problem in some way within the existing structure. This is why I added grouped search terms several years ago, to provide a way to search across multiple columns using one lookup name. I am willing to add template functions to improve things if a) their semantics can be described in a sentence or two and b) they are generally useful. A function to return the values in a grouped search term might be one example.

[eschwartz]

Originally Posted by aleyx

That solution does store the needed data correctly, but doesn't help when you want to actually use that data (i.e. in searches, filters, templates, etc) without adding max(series_*) fields, where series_* are the custom columns added.

Several use cases come to mind, but mostly short stories collections where two or more works are side-stories in their respective series. Looking for "My Series" would look like

series:"=My Series" or series_1:"=My Series" or series_2:"=My Series" or series_3:"=My Series" or series_4:"=My Series"

That would work of course, but at the cost of legibility and maintainability. Same with column colors/icons, etc.

And semntically speaking, the "omnibus" tag still kicks tuchus. Or "anthology", depending on the situation.

And to really get all the stories in perspective, especially in a short story collection, there is not and never will be any replacement for just splitting the darn things already, like normal people do.

The OP at least had an actual logical reason for wanting tag-like series', at least at first -- for crossovers, or things with subseries I guess.
The problem is as chaley said, and the reason why Kovid shoots this down every time, the challenge of implementation is WILDLY disproportionate to its return value, making it unlikely anyone will ever care enough to fix this minor niggle.

Yeah, I don't really understand either. For my part, beside the formatting point davidfor made, I'd think that Python's distutils.version would make more sense and be more flexible. But I guess perfs would take a non-negligible hit.

N.

I don't see any reason why as an end-user we should care. Other than in terms of performance, who cares what datatype is used?
Either way, having a stable decimal value allows you to make things consistent.

[jindroush]

To answer some questions:
1) I still think that natural built-in support for multiple series is the only "good thing to do". Everything else is plain hacking, with (IMO very) limited functionality.
a) for example, if I enter book into Series1 #1 and Series2 #13 using the hacks above - would I see Series2 in series browser? Would search find it? Would grid sort by it? etc.
b) similar code and approach already has to be 'inside' for multiple authors and multiple tags for one book. Yes, there should be some additional code here and there but I won't expect weeks of rocket engineering there... (Also could be done part-by-part, starting with silent update of internal db access functions)


2) I suppose my float vs integer.integer was replied by someone up there. For calibre now, 1.1 and 1.10 is the same and as someone wrote, one would have to plan in advance to accomodate sub-series number first (as 1.01 a 1.10). Which help store some stories or additional material indexes between 'main' books of series. So integer.integer is different and sorts differently than float (which is what I think calibre uses atm)


3) Similarly, [0] could be omitted from displaying, solving my beef with it


4) As I originally wrote, series ranges 1-3 could be stored as #1, #2, #3 - I still stand my ground here, but there is no problem to make gui join consecutive records as 1-3 and also allowing entering 1-3 as range (and internally storing as 1, 2, 3). Again, this could be implemented separately later.


5) I haven't tried the plugin for goodreads metadata, but clearly, it can't get all the data I'd like to see, because it has no way of storing them. It could be sufficient for basic metadata, but I'm not talking basic.


I believe everything is about priorities - and since my own priority is to be able to be synchronized with real source of metadata (in my case Goodreads), hearing that something which could be relatively simply done as 'won't implement' is a bit bummer.

[eschwartz]

Originally Posted by jindroush

To answer some questions:
1) I still think that natural built-in support for multiple series is the only "good thing to do". Everything else is plain hacking, with (IMO very) limited functionality.
a) for example, if I enter book into Series1 #1 and Series2 #13 using the hacks above - would I see Series2 in series browser? Would search find it? Would grid sort by it? etc.

Yes, yes, and yes.

b) similar code and approach already has to be 'inside' for multiple authors and multiple tags for one book. Yes, there should be some additional code here and there but I won't expect weeks of rocket engineering there... (Also could be done part-by-part, starting with silent update of internal db access functions)

Oh, good -- it appears we already have someone who knows exactly what to do. I eagerly await your patch.

2) I suppose my float vs integer.integer was replied by someone up there. For calibre now, 1.1 and 1.10 is the same and as someone wrote, one would have to plan in advance to accomodate sub-series number first (as 1.01 a 1.10). Which help store some stories or additional material indexes between 'main' books of series. So integer.integer is different and sorts differently than float (which is what I think calibre uses atm)

...or just do what I do, and don't use 0.10 to mean 0.1 (which doesn't exist).

3) Similarly, [0] could be omitted from displaying, solving my beef with it

What exactly IS you beef with it?

4) As I originally wrote, series ranges 1-3 could be stored as #1, #2, #3 - I still stand my ground here, but there is no problem to make gui join consecutive records as 1-3 and also allowing entering 1-3 as range (and internally storing as 1, 2, 3). Again, this could be implemented separately later.

That is an ugly hack. Split the book, there is a plugin to do it for you.

5) I haven't tried the plugin for goodreads metadata, but clearly, it can't get all the data I'd like to see, because it has no way of storing them. It could be sufficient for basic metadata, but I'm not talking basic.

For the odd book that actually has multiple series values, you can manually assign it.

I believe everything is about priorities - and since my own priority is to be able to be synchronized with real source of metadata (in my case Goodreads), hearing that something which could be relatively simply done as 'won't implement' is a bit bummer.

Yes it is a bit of a bummer, unfortunately that is because you are wrong -- it is not simple. So say the experts.