[dmapr]

Originally Posted by chaley

Not quite.

The name of the column has nothing to do with what happens on the reader. What I hope to be able to do is to provide a 'tweak' that indicates that *all* series columns are to be collapsed when creating collections on the reader. In other words, from the reader's point of view, there is only one column. Strange things will happen if two columns for a given book contain the same series name but different series index numbers. I cannot predict which index will be used to sort, or even if the same index will be consistently used. (Hmmm.... I suppose I could look at doing prefix matching when building collections, but then I would need some way to know what prefixes to look at. My suspicion is that doing so will complicate life beyond my willingness to deal with it, but I will think about it.)

Now to searching. What I propose and hope to be able to build is the ability to search across a set of columns sharing a common search name prefix. In your example, that prefix would be 'series'. Searching for 'series*' would check columns named series, series_1, series_2, seriesblunderbuss, etc. This allows you to search for series*:"=Jane Doe" and find values across all the matching series columns. You can search individual columns by providing its name without the '*'.

The sorting problem remains unresolved. There is no way to sort on a merger of two columns.

Note that all of these ideas are subject to Kovid's approval. He rightly does not want to add functionality that is not consistent with his plans for calibre's future.

Hmm… So, the collapsing of multiple series columns into a single collection when transferring to the reader — would that be done in Calibre or in the device plugin? If the latter, perhaps there could be a second Sony plugin with the collapsing behavior? That way it will not be interfering with the Calibre proper.

Originally Posted by chaley

The one that won't happen is a series column that can have multiple (name,index) values. The database scheme simply won't allow it, and changing the schema is too hard. Kovid is talking about someday doing a library redesign, and that is the only time when it might happen.

I wonder what the reason for the current schema is. The book-to-series has been set up as a many-to-many relationship and would've been complete had the series_index been also part of the books_series_link table instead of books table. Just out of curiosity — why was the series index not made a part of the link table?