Where is the path of an ebook determined?

[hakan42]

Hi,

I want to manage my Perry Rhodan collection with calibre, a weekly series with more than 2500 issues, and other series (about 200 issues in my collection here) that are written in the same setting, largely by the same team of authors. In this use case, this leads to a folders with hundreds of nodes in it, which slows my system down to a crawl.

This series is split into 35 sub-series which contain up to 100 issues each, of which each author writes less than 20.

I would like to modify my local version of calibre so that my directory structure would look like "<Series>/<Author>/<Title>". Before I go digging into the source code, is there any hint where I should start? I have already looked at the database schema, so I hope there is just one single place in the source where the "path" column of the "books" determined

btw, yes, I have read the FAQ and understand that kovid regards the "<Author>/<Title>" directory structure as an internal implementation detail and the GUI as the main search interface. My main problem is the slow-as-molasses implementation of the Windows filesystem as soon as it encounters directories with hundreds of nodes



Regards,
Hakan

[kovidgoyal]

set_path in database2.py

[hakan42]

Thanks :-)

Regards,
Hakan

[hakan42]

I modified database2.py and config.py to enable the behaviour I discussed in starting this post. Well, "it works for me"

Would you consider thins enhancement for 0.6.8? As far as I can determine, the default behaviour of calibre should be unchanged.

I was just about to create an enhancement ticket and attach my patch to it, but I'm getting an internal error from trac:

Trac detected an internal error:

DatabaseError: database disk image is malformed

The action that triggered the error was:

POST: /newticket

[kovidgoyal]

trac should be fixed now. I probably wont make any changes to the database in the 0.6 series. But calibre's entire database subsytem is undergoing a re-write to make it backed independent for 0.7, so at that time, I'll be happy to look at your patch.

So attach it to a ticket.

[hakan42]

Done, Ticket #3208.

Actually, I did not make any changes to the database itself, the change is only in interpretation of data that comes into construct_path_name.

Do you have any time frame for 0.7 ?


Regards,
Hakan

[kovidgoyal]

0.7 is still in very early stages, at the moment I'm still focused on bug fixing 0.6. Once that's done, I will create a public branch of 0.7 and then you can follow its development. I don't expect it earlier than the end of the year, certainly.

[hakan42]

O.k., I just have to remember patching my local installation whenever you release an update

Regards,
Hakan

[animedude01]

Originally Posted by kovidgoyal

trac should be fixed now. I probably wont make any changes to the database in the 0.6 series. But calibre's entire database subsytem is undergoing a re-write to make it backed independent for 0.7, so at that time, I'll be happy to look at your patch.

So attach it to a ticket.

I don't want to hijack the thread, but when Calibre goes backend independent, will we be able to connect to the db using multiple machines simultaneously? For example, can I set up the DB on my Linux server and have all my machines connect to it?

[kovidgoyal]

When it goes backend independent, it will be easy to add support for concurrent backends, like a MySQL server, so yes, though someone will still have to write the MySQL backend.

[hakan42]

If you need help, pencil me down for database support.

There are some use cases I'm thinking about (nothing finished to report about, just wild ideas) that would benefit from a shared database. This would make solving Ticket #2195, multiple writing clients, easier.

Regards,
Hakan

[kovidgoyal]

Cool, I'll let you know when the framework is in place.