| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
If we get a fetchMore right between when the revision was updated and
the incrementalQuery actually running, we ended up loosing the update
because the result provider ended up with a too recent revision after
the additional initial query.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
set.
We might miss some updates.
This should not normally ever happen if we assume that we have a
transaction from start to finish of the query (the maxRevision() call
should be equivalent. We do have some cornercases in our lmdb
implementation that breaks transactions when new databases are opened,
so we try to be extra safe this way....
Let's see if it works.
|
| | |
|
| |
|
|
|
|
|
|
| |
* 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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
issues.
https://phabricator.kde.org/T8723
With 200MB we can both deal with the 200MB files on disk, and we could
even load all of them (the 5 databases the resource uses), into memory.
Once the open problems are resolved we should be able to bump it back to
at least 20GB.
|
| |
|
|
| |
This triggered the assert in createIndexFromId.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Notes:
- For now, only for QDateTime indexes
- Invalid QDateTimes are stored in the index (subject to change)
- Should be a drop-in replacement from ValueIndexes (except for `In` and `Contains` queries)
Reviewers: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13105
|
| | |
|
| | |
|
| |
|
|
|
| |
We'll only end up with defunctional processes that may or may not do
anything useful.
|
| |
|
|
| |
setting it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In preparation of the support for ranged queries.
Notes:
Since they are pretty similar, it could be nice to refactor `scan` and `findAllInRange` to use common 3rd function
Test Plan: This is tested in storagetest.cpp
Reviewers: cmollekopf
Tags: #sink
Differential Revision: https://phabricator.kde.org/D13066
|
| |
|
|
|
| |
It's possible that we therefore went over the virtual address space
limit on windows which is 128GB.
|
| | |
|
| | |
|
| |
|
|
| |
Or so says the compiler.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There can only ever be one transaction using mdb_dbi_open running,
and that transaction must commit or abort before any other transaction
attempts to use mdb_dbi_open.
Use delayed dbi merging with write transactions and a temporary
transaction for read transactions.
We now protect dbi initialization with a mutex and immediately update
the sDbis hash. This assumes that the created dbis are indeed
We can still violate the only one transaction may use mdb_dbi_open rule
if we start a read-only transaction after the write transaction, before
the write transaction commits.
It does not seem to be something we actually do though.
Opening dbis on environment init is further separated out, so we don't
end up in the regular openDatabase codepath at all.
|
| | |
|
| |
|
|
| |
Required on windows in resourceconfigtest.
|
| |
|
|
| |
We run into this on windows with the resourceconfigtest.
|
| |
|
|
| |
Otherwise removal doesn't work on windows due to open file handles.
|
| | |
|
| | |
|
