| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| |
|
|
| |
First prepare the result set, then retrieve it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Because it supports std::shared_ptr<void>, which is a nice alternative
to make everything a QObject subclass for nothing.
|
| |
|
|
|
| |
The resultSet remains valid for the duration of the thread.
We keep the thread running until the ResultEmitter is deleted.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Instead of dealing with dedicated configuration facades,
we'll integrate that directly into the domain interface. That way it should
be rather natural for applications to i.e. query for available resources,
and then configure them in the same way some other domain object would be
modified.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
We indeed have to keep the facade alive, otherwise this starts crashing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It's a huge hack but starts to show results.
Most urgently we need:
* reliable command results
* the 3 buffers instead of the 1
* A way to implement storage as preprocessor (or a place to impelement it after the preprocessors).
|
| | |
|
| |
|
|
| |
handy for debug if nothing else
|
| |
|
|
| |
allowed including the header more than once ;)
|
| | |
|
| | |
|
|
|
plugins
we can divide up libakonadi2common later once we have a full collection of classes
this makes writing code a bit simpler now as we don't have to figuer out which
libraries to link against or how class dependencies should look. when we have
more infrastructure in place this will mostly become self-evident
|
