You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The no-service mode introduced in #150 works for queries that have BGP with possibly a magic property (i.e. fx:anySlot).
If you add an optional clause this will work as intended.
This is because the FXOpExecutor only overrides execute(OpBGP), execute(OpService), execute(OpPropFunc).
Therefore it only reacts to these Ops.
Also, when the engine evaluates the OPTIONAL clause, the execution context changes, and even if we've already processed the OpBGP and triplificated the source, the execution context of the OPTIONAL clause does not contain the dataset generated by the triplifier.
We only have this problem in no-service mode, because when the service clause is evaluated, each sub-operation has the triplificated dataset in its context.
To avoid this problem we can override OpExecutor.exec(Op, QueryIterator) which is the root method for evaluating the query.
To enable no service mode, we can add a flag to the execution context.
This flag is read by FXOpExecutor.exec() and if it is true, it performs the triplication as expected and adds the dataset to the execution context.
The execution can then continue with the standard Jena execution.
The OpService that is then evaluated inherits the context and thus the triplificated dataset.
Therefore, the OpService in service mode must be evaluated as a standard OpService (it makes little sense to evaluate the fx service in no service mode).
The text was updated successfully, but these errors were encountered:
The no-service mode introduced in #150 works for queries that have BGP with possibly a magic property (i.e. fx:anySlot).
If you add an optional clause this will work as intended.
This is because the FXOpExecutor only overrides execute(OpBGP), execute(OpService), execute(OpPropFunc).
Therefore it only reacts to these Ops.
Also, when the engine evaluates the OPTIONAL clause, the execution context changes, and even if we've already processed the OpBGP and triplificated the source, the execution context of the OPTIONAL clause does not contain the dataset generated by the triplifier.
We only have this problem in no-service mode, because when the service clause is evaluated, each sub-operation has the triplificated dataset in its context.
To avoid this problem we can override OpExecutor.exec(Op, QueryIterator) which is the root method for evaluating the query.
To enable no service mode, we can add a flag to the execution context.
This flag is read by FXOpExecutor.exec() and if it is true, it performs the triplication as expected and adds the dataset to the execution context.
The execution can then continue with the standard Jena execution.
The OpService that is then evaluated inherits the context and thus the triplificated dataset.
Therefore, the OpService in service mode must be evaluated as a standard OpService (it makes little sense to evaluate the fx service in no service mode).
The text was updated successfully, but these errors were encountered: