On 09.01.19 15:38, Jason E Bailey wrote:
On Wed, Jan 9, 2019, at 3:05 AM, Stefan Egli wrote:
(a) having to support job queries makes messaging-based implementations
hard. You typically don't want to do queries against a messaging system.
So this is not only about the default resource-based implementation but
allowing alternatives better.
I don't support your logic. It's a poor design to perform queries via a messaging system, but you absolutely need to be able to query 'that which is doing the processing' as to the state of the jobs.
Right, some implementation might need that, but why do you absolutely
need to expose that state in the API.
This is almost moot with a resource based implementation because it's really
easy to find that information out by looking at the resource tree. However if
the goal is to implement it in another manner then you'll need a consistent
interface to access that data.
If you're talking about doing a PDMS and you're looking at the Sling Event API
as the model for message generation across distinct micro service
implementations. I do agree that the API for the queries should be pulled out
to a separate API, that makes sense since your doing a CQRS pattern. But you're
replacing the methods not eliminating them.
What would you suggest replacing the methods with?
The problem is that your using oak queries to process data that is in a
specific location. That's not a good practice. Doing a JCR query to find
disparate resources is useful when you have a large set. When you already know
where the set of data is and your effectively using a query to filter through
the nodes. You end up killing yourself.
I can modify the code this week to be as performant as you are currently
getting with an index, without using an index, with less memory , eliminating
the whole concern of maintaining indexes.
I don't know the full history of why the index was introduced - I'm
guessing it was considered an improvement to traversing the tree
manually for doing rescans..
Cheers,
Stefan
