On Wed, Jan 9, 2019, at 3:05 AM, Stefan Egli wrote:
> The problem is two fold:
>
> (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. 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.
> (b) in order to support queries in the existing resource-based
> implementation we're using indexes already. So the query itself is not
> expensive - but maintaining the index is a cost which you don't need to
> do if there wouldn't be any query to support in the first place.
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.
