| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
QVariant doesn't support polymorphism for non-QObject classes.
|
| | |
|
| |
|
|
|
|
|
|
| |
* Smarter caching. ResourceAccess instances close after a timeout, if not reused.
* Introduced a start command to avoid race condition when sending
commands to a resource that is currently shutting down.
* We resend pending commands after we lost access to the resource
* unexpectedly.
|
| |
|
|
|
|
|
|
|
| |
We want one connection per application per resource instance.
With this change the connection is maintained for the lifetime of the
client process (it should probably time out instead), but we at least
avoid creating a connection per operation/query, which results in
a significant performance boost (~10% for reading, 90% for writing in
dummyresourcebenchmark).
|
| |
|
|
|
| |
Since we can now inject entity ids we have to ensure they are not
already existing.
|
| |
|
|
|
| |
We had quite a bunch of superfluous notifications before (i.e. during
cleanup).
|
| |
|
|
|
|
|
| |
Remote id's need to be resolved while syncing any references.
This is done by the synchronizer by consulting the rid to entity id
mapping. If the referenced entity doesn't exist yet we create a local
id anyways, that we then need to pick up once the actual entity arrives.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The fetch state is per parent.
|
| | |
|
| |
|
|
| |
We go rid of large parts of the header entanglements.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The QueryRunner object lives for the duration of the query (so just
for the initial query for non-live queries, and for the lifetime of the
result model for live queries).
It's supposed to handle all the threading internally and decouple the
lifetime of the facade.
|
| |
|
|
|
| |
Although, the benchmarks say it doesn't really have an impact on
performance.
|
| |
|
|
| |
Without this modifications are ignored also in incremental queries.
|
| | |
|
| | |
|
| |
|
|
|
| |
This just gave a 700% boost to query performance from ~2k
to 14k reads per second...
|
| |
|
|
|
| |
That way we don't have to hardcode the parent property,
and we can use the property to express non-tree queries as well.
|
| | |
|
| |
|
|
| |
We're not doing partial fetches yet
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
I finally figured out how to do that with cpp files.
It requires instantiating the code with all expected classes,
but that's not a big problem since we know all types.
This will hopefully greatly reduce the compiletimes...
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We're not doing any lifetime management anyways.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
sync has been removed from the query code and is now a separate step
|
| | |
|
| |
|
|
|
| |
The result model drives the data retrieval and provides the interace
for consumers
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Misses tests.
|
| | |
|
| |
|
|
| |
... also if there are intermediate revisions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having the asynchronous preprocessor concept with different
pipelines for new/modify/delete we have a single pipeline with
synchronous preprocessors that act upon new/modify/delete.
This keeps the code simpler due to lack of asynchronity and keeps the
new/modify/delete operations together (which at least for the indexing
makes a lot of sense).
Not supporting asynchronity is ok because the tasks done in
preprocessing are not cpu intensive (if they were we had a problem
since they are directly involved in the round-trip time), and the main
cost comes from i/o, meaning we don't gain much by doing multithreading.
Costly tasks (such as full-text indexing) should rather be implemented
as post-processing, since that doesn't increase the round-trip time directly,
and eventually consistent is typically good enough for that.
|
| | |
|
