So I'm missing something here, from what I gather so far, the methods that are being deprecated are to prevent a performance issue but the node structure that represents the jobs is in one place isn't it? How in the world are we getting a performance issue from that?
Is there a use case to demonstrate the performance problem? -- Jason On Tue, Jan 8, 2019, at 11:12 AM, Carsten Ziegeler wrote: > Hi, > > I agree, variant B sounds like the better option due to the reasons you > mention. It also provides a step by step way of moving a single type of > jobs to not use search anymore. > > The only downside is that this doesn't force anyone to think about her > job usage as everything just runs as before. Only if you want to improve > you can and adjust the configurations. > > > Regards > > Carsten > > > Stefan Egli wrote > > 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.. > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
