Quote:
Originally Posted by kovidgoyal
Additions via calibredb without a server are going to be slow, because the library has to be opened and read into RAM for each invocation.
|
That definitely aligns with what I see.
It never occurred to me that it would do that (I mean, I think I saw that described in documentation, but forgot until you mentioned it).
And changing to query as needed would be a significant architecture change, wouldn't it?
Right now the process via calibredb takes about 21 seconds per title, with having half a dozen calls per addition.
I wonder how difficult it would be to add a couple new parameters to 'calibredb add':
- -p PUBLISHER, --publisher=PUBLISHER (seems to be missing)
- -m METADATA, --metadata=METADATA, which can take multiple metadata fields at once, including custom.
METADATA takes the form field:'value',field:'value',*field:'value',*field: 'value' (identifiers:'isbn:#####,asin:#####').
We can mix built-in and custom columns in other contexts, so I hope we can do the same here.
I'd be inclined to add the same -m/--metadata to set_metadata (doesn't affect those who use it today because they're using -f).
$ calibredb set_metadata -m *own:1,*source=OneBookShelf,*filename='somefilenam e.pdf',*filepath='o:/DriveThruRPG/Some Publisher',*filesize=3183845 11345
[hmm, weird. when I preview I see an extra space in 'somefilename.pdf' that I didn't put in]
would let me do all the metadata in one pass... and if the change is made to calibredb add, I can do both steps at once and reduce the entire thing to a single call.
It looks like using an OPF file can reduce the metadata setting to a single call (custom columns look kind of complex in the OPF file). It looks like adding a file won't accept an OPF, though.