| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The queryrunner is responsible for running queries and keeping them
up to date. This is required for self-updating queries.
To get this to work properly the ResultProvider/emitter had to be fixed.
The emitter now only lives as long as the client holds a reference to
it, allowing the provider to detect when it is no longer necessary to
keep the query alive (because noone is listening).
In the process various lifetime issues have been fixed, that we're
caused by lambdas capturing smartpointers, that then extended the
lifetime of the associated objects unpredictably.
|
|
|
|
|
| |
We want to keep the command until we know it arrived in the resource,
so we can resend it otherwise.
|
|
|
|
| |
Still not quite there but we're avoiding the bulk of duplication by now.
|
| |
|
|
|
|
|
| |
This should cover read and write for entites that have a 1:1 mapping to the
resource buffers.
|
| |
|
| |
|
| |
|
|
|
|
| |
Because it's really the application domain and not the akonadi domain.
|
| |
|
| |
|
|
|
|
|
| |
All identifiers should be latin1 and we make this explicit by using
QByteArray. QString is reserved for strings that can be UTF-8 or alike.
|
| |
|
| |
|
|
|
|
|
|
| |
Ideally we wouldn't be copying at all, and somehow cast the table to a vector.
Unfortunately I haven't figured out how to do that, and this solution at least
gets us from 0.065 ms to 0.028 ms in testCreateCommand.
|
|
|
|
|
|
|
|
|
|
|
| |
It's lifetime is limited to the end of the function, so we have to copy it before.
I switched to QByteArray because it simplifies the code and shouldn't really
cost anything, additionally the implicit sharing makes copies cheap.
This patch incurs the cost of always copying the buffer instead of writing
straight to the socket, but we probably anyways want to keep a copy around,
and if it would indeed be a performance issues (I doubt it), we could still optimize
that copy away.
|
| |
|
|
|
|
| |
We indeed have to keep the facade alive, otherwise this starts crashing.
|
| |
|
| |
|
|
|
|
|
| |
There's a chance that the resource actually wanted to shut-down. Instead
ResourceAccess should only reopen the connection if it still has work to do.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Otherwise the client always restarts the resource because of the lost connection.
We currently require this in tests to be able to delete the db, but eventually
we likely want a "disable akonadi" function that shuts resources down,
and keeps clients from restarting them (e.g. via configuration).
|
| |
|
|
|
|
|
|
|
|
|
| |
When user gets a Job (from a method call for instance), which is already running
or might have even finished already, they can still append a new Job to the chain
and re-execute it. The Job will internally chain up to the last finished Job, use
it's result and continue from the next Job in the chain. If a Job in the chain is
still running, it will wait for it to finish and pass the result to the next Job
in the chain.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now it's possible to do something like
Job<int, int> job = createSomeJob();
auto main = Async::start<int>(....).then(job);
Previously the 'job' would have to be wrapped in a ThenTask-like lambda (which
is what we still do internally), but with this new syntax it's possible to append
another job chain to existing chain easilly. This syntax is available for all
task types.
|
| |
|
|
|
|
|
| |
equivalent syntax, but follows the standard idiom we use throughout
the code .. const char *, not char const * (e.g.)
|
|
|
|
| |
Work for dvratil.
|
| |
|
|
|
|
|
| |
Otherwise the synchronizer keeps a Storage object alive, while the tests
deletes the db. This causes subsequent writes to fail in the next test.
|
| |
|
| |
|
|
|
|
| |
instead, use the lmdb api
|
| |
|
|
|
|
|
| |
The job currently finishes synchronously. If we just use the eventloop in waitForFinished
that's automatically handled for us.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As queries become reactive this should become less important. We can then just wait until
all results become available. For tests it is in either case useful though.
|
|
|
|
| |
...and a couple of other fixes.
|
| |
|
| |
|
| |
|
|
|
|
| |
until signalling completion.
|
| |
|