Quote:
Originally Posted by theducks
↑ ↑ ↑ ✔
{Date} has a purpose as David noted, and I belong to the school of 'leave the purpose intact'.
I know many others reuse columns for their own tasks, but we have the option to add our own and not mess with the data.
"When did I add this to Calibre? Oh! #$%, I reused the {Date} for last xyz"
Numbers, Dates, Logical (T/F) add a small bit of DB size, (unlike some of the others.) and take almost no performance hit (unlike calculated from other fields). So that should not be a major issue deterring making your own Date
and it avoids 2 different PI re-purposing (then later come here asking WHAT is messing with my last_read date.  |
It's a fair point. But I'm curious how you think about my situation.
I used a different program that had a date field with the identical semantics of Calibre. The date field represented when the record was created in that program.
I exported that program's information to a CSV and now want to import it to Calibre.
I'd like to exactly re-hydrate the information from the other program in Calibre so that I can order by the Date column and know it represents when I added the content (which is not the same as when I read the content, in many cases that was months before the add date).
How would you suggest I create that experience in Calibre? And ideally how can I create it without having to constantly type dates in an extra field for every new book I add forever. That is just going to be really annoying. Especially when I forget to do it and a book gets "lost". So now I have to go write some kind of logic to detect missing dates and fix them.
Thoughts?