Hi,
I've given this job query issue some more thought and would like us to
discuss and hopefully soon agree on which way we go:
Variant A: deprecate job query methods (as suggested originally):
* upside: eventually we'll have a cleaner job API
* downside: users of the job query API need to find alternatives to
queries, individually
Variant B: allow disabling job queries (https://s.apache.org/68ys):
* upside: allows performance optimizations on a case-by-case basis
(optimizations include not requiring indexing), thereby promoting
query-less use cases going forward without API deprecation nevertheless.
* downside: we stick to the current job API
Note that in both cases the 'org.apache.sling.event.jobs' export version
will have to be updated from 2.0.1 to 2.1.0 - which will affect
users/customers that implement interfaces from that package (that's not
something typical though, but there are a few exotic cases where that's
the case).
At this stage I'm in favour of variant B as I don't see a good
alternative for job queries other than users re-implementing a fair
chunk of the sling event implementation themselves (which would sort of
defeat the purpose, besides the fact that it would not be trivial as
there aren't enough hooks in the API for anyone other than the
implementor to do this consistently).
Cheers,
Stefan
On 17.12.18 16:08, Stefan Egli wrote:
We could introduce a config option which would allow a job queue to
opt-out of job queries voluntarily. That would allow the implementation
to treat those jobs differently (cheaper, without indexing them).
I guess such a new opt-out of queries mechanism could be less
controversial and provide at least some short-term gain. It doesn't
answer the question how job queries should be replaced though..
