[Feature suggest] Maintenance option: Reindexed the library

[un_pogaz]

First one, a trivial question:
What is the theoretical limit of the library index?
I guess that's an unattainable number, but I'm curious

The thread question:
Would it be possible to make an option of maintenance of the library which allows to re-index the books and to fill the possible voids in the numbering?


So, Yes, I know this is a very delicate operation. The user interface must ther be frozen to prevent any library modification during the process.
But as the operation can be very long, it would be necessary to leave a button "Stop reindexing". Once this button is clicked, Calibre finishes the current book then release the user control.

_____________

Currently, when a book is added, Calibre gives it "last index+1". It is a simple solution, fast and without headache.
I'm nothing against it, and it would be monstrously and unnecessarily complicated to test the free indexes when adding a book (and slowed Calibre)

But, a separate maintenance option, why not.

[Terisa de morgan]

As somebody who comes from the software world, unless you reach the limit of the index (maximum number allowed by the size of the field), it doesn't make sense for me

[DaltonST]

Good joke. Very funny. It makes me smile. Have a nice day.

[un_pogaz]

Originally Posted by Terisa de morgan

As somebody who comes from the software world, unless you reach the limit of the index (maximum number allowed by the size of the field), it doesn't make sense for me

Badum Tsss

[Terisa de morgan]

Originally Posted by un_pogaz

Badum Tsss

Mí no comprender.

[Adoby]

The procedure is: (not tested...)

Save all your books to disk, making sure to save covers and complete updated metadata in opf:s.
Create a new empty calibre library, with the same structure as the old.
Import all the saved books to the new library, reading metadata from OPF:s.
Enjoy lovely low index numbers without gaps. For a while...

Test first on a small representative subset of books...

It is essentially a database dump and restore from dump. I remember when that was the usual way to speed up and compact databases...

[theducks]

Originally Posted by un_pogaz

The thread question:
Would it be possible to make an option of maintenance of the library which allows to re-index the books and to fill the possible voids in the numbering?

I was taught to NEVER reuse an (key)index, least an orphan became reattached.


OTOH Doing the Copy To Library gives the book a new assignment (and is not susceptible to orphans) as part of the task. If the destination starte empty, they will be sequential

[BetterRed]

@un_pogaz - why do you care?

BR

[kovidgoyal]

There's never going to be such a feature. book ids are meant to be stable, they are for instance, used in content server urls. You can of course do it yourself by using various tricks such as copy to library to a new library, but I strongly recommend against it.

[un_pogaz]

@BetterRed Why not ? More precisely, I see my library growing more and more, I am not worried, but just curious.


@Adoby Nope,I don't recommend this method. The best is what Kovid suggests: Move your library in a another via Calibre. Use "Save to disk" would be doubly longer (writing then adding) and uncertain.


@kovidgoyal Yes, it is an easy solution that has the merit of already being implemented.
However, it has a flaw: The "Move books" function copies all books and deletes all books only if the operation ends normally.
If the operation is interrupted, even via the button designed for, the books already copied are not deleted from the source library. Result, duplicates between the 2 libraries.

A mass move (Select all > Move to library) is such an enormous risk that it makes it impossible.
So you stay in front of Calibre and move your library, 100 by 100 (for exemple), manually.

One solution would be to copy the books and delete them 1 by 1, gradually. This might be slower than the current method, but it would be a true "Move to library" function.
I leave you to judge this change.

Thank for answer

[BetterRed]

@un_pogaz - why renumber the Books table, and not the other tables with auto incremented primary keys, viz:



This may be of interest ==>> Implementation Limits For SQLite.

BR

[un_pogaz]

From the page Implementation Limits For SQLite

Maximum Number Of Rows In A Table

The theoretical maximum number of rows in a table is 264 (18446744073709551616 or about 1.8e+19). This limit is unreachable since the maximum database size of 140 terabytes will be reached first. A 140 terabytes database can hold no more than approximately 1e+13 rows, and then only if there are no indices and if each row contains very little data.

Maximum Database Size

Every database consists of one or more "pages". Within a single database, every page is the same size, but different database can have page sizes that are powers of two between 512 and 65536, inclusive. The maximum size of a database file is 2147483646 pages. At the maximum page size of 65536 bytes, this translates into a maximum database size of approximately 1.4e+14 bytes (140 terabytes, or 128 tebibytes, or 140,000 gigabytes or 128,000 gibibytes).

18446744073709551616 row or/and 140 terabytes database size

Hum
I think we can rest easy.

[DoctorOhh]

Originally Posted by un_pogaz

Hum
I think I can rest easy.

I corrected it for you, peace.