-
-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for library reloading #636
Conversation
Reused `Library::getArchiveById()` in `Library::getReaderById()`.
Codecov Report
@@ Coverage Diff @@
## master #636 +/- ##
==========================================
+ Coverage 66.62% 67.17% +0.55%
==========================================
Files 53 53
Lines 3823 3906 +83
Branches 1931 1979 +48
==========================================
+ Hits 2547 2624 +77
- Misses 1274 1281 +7
+ Partials 2 1 -1
Continue to review full report at Codecov.
|
c2c35d3
to
6884386
Compare
New unit test BookTest.getHumanReadableIdFromPath revealed a bug in `Book::getHumanReadableIdFromPath()`.
6884386
to
191096c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've nothing to say about the quality of the code itself here. Really good as usual.
I'm a bit disturbed by the ReloadableLibrary
.
The idea was to have the Library
as a "simple" container of book and have all manipulation of the library put elsewhere (Manager
/Manipulator
)
The ReloadableLibray
takes the opposite direction by creating a library which knows from what is was created and can reload itself.
I would have extend the Manager
to be able to do a "diff" between the "library.xml" it is reading and the Library
it is managing and apply this "diff" to the Library
What about multithreading ?
We will reload the library while a server will run in the same time.
We must be prepared to concurrent access/modifications.
And we need book removal.
The new library.xml
will have new books added and old books removed. We must correctly handle this
Fixed the build failure caused by the libkiwix API changes done in kiwix/libkiwix#636.
Library is now thread safe as long as its usage in kiwix-serve is concerned.
Added prototype support for book removal during library reloading that neglects |
8078190
to
900eb8e
Compare
900eb8e
to
95658fb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you don't object against my approach, then respecting LibraryManipulator should not be a problem, though there are several options to do that.
Marking the book updated is a good enough way to detect books not updated.
In this PR you modify a bit the LibraryManipulator
to provide a default implementation and also a bit the behavior of the Manager
(The Manager
is not a one shoot object but it is keep alive to be reused).
I'm not against those changes, on the contrary. If you think we can go further to reorganize all those different classes, please do not hesitate to do it (maybe not in this PR, or open a discussion to be sure about what we can do).
if ( ! booksReferToTheSameArchive(oldbook, book) ) { | ||
dropReader(book.getId()); | ||
} | ||
oldbook.update(book); // XXX: This may have no effect if oldbook is readonly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know why we have this "readonly" attribute on the book.
This is something pretty old and we don't use it at all. Maybe @kelson42 knows why it has been introduced.
But if you want to drop it, I agree 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If @kelson42 doesn't come up with arguments against removing Book::m_readOnly
I will do it in a separate PR.
Please rebase-fixup and we can merge. |
The right place for NameMapperProxy introduced by kiwix/kiwix-desktop#714 is in libkiwix (so that it can be reused in kiwix-serve).
Originally `LibraryManipulator` was an abstract class completely decoupled from `Library`. Its `addBookToLibrary()` and `addBookmarkToLibrary()` methods could be defined in an arbitrary way. Now `LibraryManipulator` has to be bound to a library object, those methods are no longer virtual, they always update the library and allow for some additional actions via virtual functions `bookWasAddedToLibrary()` and `bookmarkWasAddedToLibrary()`.
Introducing a mutex in `Library` necessitates manually implementing the move constructor and assignment operator. It's better to still delegate that work to the compiler to eliminate any possibility of bugs when new data members are added to `Library`. The trick is to move the data into an auxiliary class `LibraryBase` and derive `Library` from it.
Library became thread-safe with the exception of `getBookById()` and `getBookByPath()` methods - thread safety in those accessors is rendered meaningless by their return type (they return a reference to a book which can be removed any time later by another thread).
3a127e4
to
405ea29
Compare
Done (also fixed a few typos noticed during the final quick review). |
Fixed the build failure caused by the libkiwix API changes done in kiwix/libkiwix#636.
Enables kiwix/kiwix-tools#497 to fix kiwix/kiwix-tools#243
This PR provides facilities for reloading and updating the library with any of
The PR also includes various improvements/bugfixes noticed while working on this PR, as well as a few new unit-tests.
API changes introduced by this PR are addressed in kiwix-desktop by kiwix/kiwix-desktop#732.