Quote:
Originally Posted by DavidTC
A better solution is to just tell Calibre that the Series field is a hierarchy, which lets it expand outward in the views. If you look at where that page shows 'Categories with hierarchical items', you'll see that whoever made that example image already has 'series' in there. So just make sure that's there, and you can put the series as 'Star Trek.The Next Generation [80]' or whatever.
(Pre-defined columns are referenced like 'series' and 'tags', custom columns have a pound in front of them like '#genre'.)
|
Clever. I use a lot of hierarchical columns, but I never thought of doing the series that way.
I do see one problem with this method, however. Using your Star Trek example, let's pretend that you've named your "subseries" as "Star Trek" and "Next Generation".
You'll end up with the following in your series column if you sort by series:
Star Trek.Next Generation[1]
Star Trek.Next Generation[2]
...
Star Trek.Star Trek[1]
Star Trek.Star Trek[2]
...
This is because the "N" in "Next Generation" preceeds the "S" in "Star Trek". With this system, you don't have all the information you need, specifically, the fact that the Next Generation books take place after the original series books.
It gets even more complicated when you have concurrent subseries and sometimes you need to read them in a particular order. Take the Pern books, for instance. The "official" reading order is the order of publication, which means you have to jump back and forth between different subseries. With a hierarchical series column, the series order is not the correct reading order.
Quote:
Originally Posted by DavidTC
This...is not a good idea. If you could actually import books with their paths ending up in a column like that, it'd be a useful stopgap measure to help deal with things...but you can't import like that, so you'd end up just typing that column in. Don't do that. It accomplished nothing. All you've done is now put stuff in two different places, and have to keep them both up to date, which is exactly what you don't want to do in a database.
If you want to export books, to an ereader or something, as {#genre}/{author}, you can trivially tell Calibre to do it like that. If you really wish to *view* the books in the list like that (?!), you can make a custom column that contains that value automatically, although that's something that doesn't really make sense vs. just filtering on genre and sorting by author.
Not that you've actually said you want to do that anyway. I'm just saying, in case you wish to do that, do not follow the advice of spending your time putting a hand-made *path* inside the database for no reason, when Calibre can actually generate it for you using values already in there.
|
These are some good points. However, I will defend my use of a path field by saying that the convenience of using it outweighs the inconvenience of maintaining it twice. Some points to consider:
1. It turns the tag browser (conveniently located on the left) into something akin to the left-hand pane of Windows Explorer or other file managers. Having the books organized by folders and subfolders feels comfortable for someone used to a hierarchical file system. So you get both the versatility of Calibre's library management, AND the familiarity of a hierarchy. It's a possible answer to those complaints of "Why can't I store my books in my own folder structure?"
2. It makes the Save-To-Disk template easy if you ever want to export your books back out to your hard drive and keep the original folder structure.
3. Speaking of Save-To-Disk templates, I use this field in all my physical libraries, where the hierarchy is vastly different. This makes it so I can use the same Save-To-Disk template for all my libraries instead of having to use a switch in the template based upon the library name (and having to update the template if I ever add a new library).
4. You could, theoretically, set up the path field as a column created from other columns. That would make it easier to maintain. However, that only works if your hierarchy structure is consistent across multiple genres. For instance, I might want my Fiction books sorted by genre and author. But if I liked to read biographies, it might be more appropriate to sort it by the person who the biography is about. History books might be more appropriately sorted by event. Even the number of levels in the hierarchy might change across genres.
5. Setting it up initially on a large library is, admittedly, a lot of work. But once you have it the way you want, it's just one more column you have to populate when you add new books to your library. Assuming you're only going to be adding a few books at a time, in most cases you can just drag and drop them into the correct path in the tag browser. Or use Bulk Edit Metadata (which I find myself using frequently when adding new books anyway). It's really not that much work to maintain it.
The way I see it, the Path column is really no different than organizing your books by folder and subfolder on your hard drive. Yes, it's redundant in some cases. But so is putting books by Charles Dickens into a "Dickens, Charles" folder on your hard drive. After all, the author's name is already in the ebook's metadata. Putting the book into a folder is an extra step that adds no information.