Quote:
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
Code:
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.
Quote:
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.