| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Change revision type from `qint64` to `size_t` for LMDB in a couple of places (LMDB supports `unsigned int` or `size_t` which are `long unsigned int` on my machine)
- Better support for database flags (duplicate, integer keys, integer values for now but is extensible)
- Main databases' keys are now revisions
- Some databases switched to integer keys databases:
- Main databases
- the revision to uid mapping database
- the revision to entity type mapping database
- Refactor the entity type's `typeDatabases` method (if in the future we need to change the main databases' flags again)
- New uid to revision mapping database (`uidsToRevisions`):
- Stores all revisions (not uid to latest revision) because we need it for cleaning old revisions
- Flags are: duplicates + integer values (so findLatest finds the latest revision for the given uid)
~~Problems to fix before merging:~~
All Fixed!
- ~~Sometimes Sink can't read what has just been written to the database (maybe because of transactions race conditions)~~
- ~~Most of the times, this results in Sink not able to find the uid for a given revision by reading the `revisions` database~~
- ~~`pipelinetest`'s `testModifyWithConflict` fails because the local changes are overridden~~
~~The first problem prevents me from running benchmarks~~
Reviewers: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D14974
|
| |
|
|
|
|
|
|
| |
* Modifications could result in index changes because we lost the
threadId due to remove + add. A modify was necessary (although we can
ignore it for the email case).
* The ThreadIndexer would try to lookup and potentially index threads
for empty parent ids, which is clearly wrong.
|
| |
|
|
|
| |
This cuts into the sync performance by about 40%,
but gives us fast fulltext searching for all local content.
|
| | |
|
| | |
|
| |
|
|
|
| |
It can happen that thread messages are not delivered in order, which
means we will have to merge threads once all messages are available.
|
| | |
|
| |
|
|
|
| |
It seems to do more harm than good, creating huge threads,
and the webclient doesn't do it either.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Ensure we always have a messageId to work with,
and avoid grouping all non-threaded messages together.
|
| | |
|
|
|
complex than a simple key-value pair.
|
