cubicweb #2807739 transform call_service into a simple synchronous in-process (still appobject based) Repository extension mecanism [validation pending]
Let's give it a proper name ("repo-method"), as in::
vreg['repo-method'].select('wipe-all-caches', butnot=('querycache',)) | |
priority | normal |
---|---|
type | enhancement |
done in | 3.19.0 |
load | 0.400 |
load left | 0.000 |
closed by | <not specified> |
Comments
-
2013/04/09 12:53, written by pydavid
-
2013/04/09 12:59, written by acampeas
-
2013/04/09 13:05, written by pydavid
-
2013/04/09 13:19, written by acampeas
add commentWe need a proper way to call repo side function from anywhere. The current call_service API is messy and mixed. We need something better but we can not left orphaned use case.
The first step is about a clear separation between sync clal with return and async notification.
The first step is to reconsider use cases and act apropriately.
There is exactly one _current_ use case for call-service (controller + deferred execution). We don't need call-service for this.
For repo side function call from anywhere, as I previously said, we should use a task distribution mechanism such as the one present in the worker cube.
Can you think of more use cases ?
The "vcs.export-rev" function is very good example of "code that are needed anywhere but need to be run repo side". You can find tens of such function in application cubes. They are usually monkeypatched on the repository as a work around.
The task distribution mechanisme as the worker cubes have nothing to do with those use case.
The initial usecase for call service (deffered async execution) can be achieved with a notificiation mechanisme close to what we do now.
Without saying it, you are really talking about the web/client | repository fence.