-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved custom service executor extension system #1387
Comments
Please explain what is going on here and why these changes are necessary This is a repeat comment from before - I am concerned that changes to central machinery for one particular usage will have consequences for other users that are hard to predict. Did you consider batching inside the service execution reading from the Why is single treated different from a bulk of one? |
Batching based on "push-events" to As an example why I am not blindly batching by n bindings: It would be easily possible adding a subclass of However, e.g. in #1314 I created conceptually a This is a bit smarter than blindly batching unrelated bindings.
Well, the single API is a special case of the bulk one - and the bulk one delegates to it. So its not really treating it differently but rather having two reasonable levels of abstraction (That's why I let QueryIterRepeatApply extend from QueryIterRepeatApplyBulk) - maybe the latter should be called simply |
I gave the QueryIteratorRepeatApply more thought and it turns out the extension system doesn't need a dedicated QueryIterator at all. Only the This means I can revert QueryIterRepeatApply. I am also looking into combining the bulk and single registry into a one class (I am just not yet sure whether this internally uses the two existing registries or its own set of attributes). |
W.r.t. to the comment that this is just for my solution: The bigger picture is that I would really love to have an infrastructure/path where it is possible to combine SERVICE plugins of different third-party systems such as those of sparql-anything (this is their OpExecutor*) - and of course those developed in my group. (Whether and when they'd upgrade is of course their choice.) Back then I reached out with sparql-anything issue 60 * Most work there happens in OpService; yet there is one override for OpBGP which extracts options from triples - similar to what stardog does. This would also be interesting to have as a future extension point but I don't think this has to be be a concern for this PR. |
GH-1387 Improved custom service executor extension system
Version
4.6.0-SNAPSHOT
Suggestion
This is the issue for factoring out the extension system itself from #1314 so it can be reviewed in isolation.
Link to PR: #1388 (see it for detailed comments)
Are you interested in contributing a solution yourself?
Yes
The text was updated successfully, but these errors were encountered: