| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This fixes the performance regressions to a state where we are roughly
at the same performance as pre Identifier (but not any better either).
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D14099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Only in TypeIndex, not in Index (since we might want to store something other than identifiers as values)
- We might want to do the same in the `SynchronizerStore` for localId ↔ remoteId indexes
Depends on D13735
Some quick benchmarks (against develop and D13735): {F6022279}
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Use object oriented paradigm for Keys / Identifiers /Revisions
- "Compress" keys by using byte representation of Uuids
- Still some cleaning left to do
- Also run some benchmarks
- I'm questioning whether files other than entitystore (tests excluded) are allowed to access this API
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13735
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The case we ran into is the following:
* Fetching the full payload and marking all messages of a thread as read
happens simultaneously.
* The local modification to mark as read gets immediately overwritten
when the full payload arrives.
* Eventually the modification gets replayed to the server though (and
the reversal isn't because coming from the source), so on next sync the
situation fixes itself.
To be able to improve this we try to protect local modifications in that
properties that have been modified since baseRevision (which currently
isn't, but should be equal to the last to the server replayed revision)
are not overwritten. This conflict resolution strategy thus always
prefers local modifications. baseRevision is currently set to the
current maximum revision of the store at the time when the resource
creates the modification.
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Notes:
- Introduces the concept of queries on multiple properties (which meant changing query's internals a bit)
- Dates are stored as well as the "reference" in the index to allow quick filtering without fetching the whole entity
- Buckets are weeks starting on Monday (guaranteed by the use of the Julian calendar)
- Some size improvements are definitely possible (dates are padded numbers again, not using integer databases, Julian calendar starts at a very old date, etc.)
Test Plan: Tested in querytest
Reviewers: cmollekopf
Reviewed By: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13477
|
| |
|
| |
|
|
|
|
|
| |
Otherwise we easily end up copying it and then have an entity that
points into nowhere. Callback -> no copy, no callback -> copy.
|
|
|
|
|
| |
Seems to be happening sometimes, so that needs to be fixed once we find
the cause.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Like the title says.
Also removed a "/" that got doubled between the collection URI and the item path, because it made Cyrus freak out (returning unauthorized errors)
Reviewers: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D12755
|
|
|
|
| |
version when creating it
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A single QueryRunner should never have multiple workers running at the
same time. We did not properly enforce this in case of incremental
updates coming in.
The only way I managed to reproduce the crash:
* Open a large folder with lots of unread mail in kube
* Select a mail in the maillist and hold the down button
* This will:
* Repeatedly call fetch more
* Trigger lot's of mark as read modifications that result in
notifications.
* Eventually it crashes somewhere in EntityStore, likely because
of concurrent access of the filter structure which is shared through
the state.
We now ensure in the single threaded portion of the code that we only
ever run one worker at a time. If we did receive an update during,
we remember that change and fetch more once we're done.
To be able to call fetch again that portion was also factored out into a
separate function.
|
|
|
|
|
| |
This cuts into the sync performance by about 40%,
but gives us fast fulltext searching for all local content.
|
| |
|
|
|
|
|
| |
We used to simply return all uids.
Requires "sinksh upgrade"
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Creating the directories is way more expensive than searching through
the files on removal.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
lmdb and sink deal badly with e.g. a string containing a null in the
millde as db name. Thus we try to protect better against it.
This is an actual problem we triggered: https://phabricator.kde.org/T5880
|
| |
|
|
|
|
|
| |
This is where this really belongs, only the indexing is part of storage.
This is necessary so preprocessors can move entities as well.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Having them separated is rather pointless (since we need one for every
type, and all types are the interface of sink, as one), and caused quite
a bit of friction when adding new types. This will also make it easier
to change things for all types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dbis can only be opened by one thread and should then
be shared accross all threads after committing the transaction
to create the dbi.
This requires us to initially open all db's, which in turn requires us
to know the correct flags.
This patch stores the flags to open each db in a separate db,
and then opens up all databases on initial start.
If a new database is created that dbi is as well shared as soon as
the transaction is committed (before the dbi is private to the
transaction).
|
|
|
|
|
| |
...we used to accidentally move external blobs after the property was
lost when storing the modificatoin in the queue.
|
| |
|
| |
|
| |
|
| |
|