Make SqliteStorage independant of any calendar. #28
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dcaliste
force-pushed
the
nocalendar
branch
8 times, most recently
from
ef39bfd
to
b0e0aff
Compare
This class is a subset of old ExtendedStorage one, with method purely related to storage handling, without any relation to a calendar. Make SqliteStorage inherits of this new class. Implement ExtendedStorage as a backend for a calendar, using only observers. ExtendedStorage is necessarily a SQLite one now.
Don't assume that incidences are shared pointer when it's not necessary, like in internal database read/write or alarm handling.
Storage backends are not using ::Ptr anymore, the memory management is delegated to a Manager of the storage backend. The manager can take ownership of the new notebooks and new incidences.
|
This is now superceeded by #37. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@pvuorela, this is an attempt implementation of some ideas we exchanged on IRC about making the SQLite storage independant from any calendar. The overview is the following :
StorageBackendclass that takes the methods from ExtendedCalendar related to database handling but that does not require any calendar, just incidences and their notebook ids.ExtendedStoragea link between the SQLite backend storage and an ExtendedCalendar, using only observer methods. To keep backward compatibility on it, it is inheriting SqliteStorage instead of CalStorage now. The previous behaviour should be kept.From a positive point of view, tests are still passing. From a negative one, I had to break the API compatibility on ExtendedStorageObserver, since it has been moved to StorageBackend. As far as I know, it was only used in the QML binding (recent addition, you know) and it should be simple to update it.
Some technical notes :
QMultiHash<QString, Incidence::Ptr>containers. Such containers have been typedef toCollectionfor briefty.I'm submitting this before implementing the threaded version to discuss with you if it's valuable or going in the right direction. If so, I'll create a
ThreadedStorageclass that will basically do the same than the currentExtendedStorageone but with the SQLite backend living in a different thread.