I have worked out the details and propose we write a triplefunction that accepts the following parameters:
search:search(query, subject, propertyPredicate, property, scorePredicate, snippetPredicate) [functional, not spin syntax]
where
query is the query string
subject is the query subject or the constant search:allMatches
propertyPredicate is the constant search:property or not present
property is present if only propertyPredicate is present and is the property to query or the constant search:allProperties
scorePredicate is the constant search:score or not present
snippetPredicate is the constant search:snippet or not present
the output should be in this order
subject, property, score, snippet
where
subject is included if the subject parameter is search:allMatches else omitted
property included if the propertyPredicate parameter is present and the property parameter is search:allProperties else omitted
score is included if the scorePredicate is search:score else omitted
snippet is included if the snippetPredicate is search:snippet else omitted
As a spin magic property, examples would be
(?subject ?score ?snippet) search:search("test" search:allMatches search:property x:myprop search:score search:snippet)
(?property ?snippet) search:search("test" x:me search:property search:allProperties search:snippet)
Now for the search syntax, the syntax stays the same. We still produce a QuerySpec, but we will convert the QuerySpec into a TupleFunctionCall of the above form. We can then replace the search syntax StatementPatterns in the query tree with this TupleFunctionCall and send it for (late) evaluation instead of the current early evaluation and replacement with a BindingSetAssignment.
Now for evaluation, the bean injection problem can be solved via ThreadLocal as I think you mentioned, or at evaluation time, creating a private TupleFunctionRegistry instance, create a SearchTupleFunction instance and passing the search index beans in the constructor, and adding the function to the registry. I believe this registry can then be passed in to TupleFunctionEvaluationStrategy rather than using the default static TupleFunctionRegistry. The ThreadLocal approach would have the advantage that the TupleFunction could be used as a spin magic property with spin as well as with the search syntax in the lucene sail (and any other magic property syntax). And, I think we can re-use the spin QueryContext thread-local by having a QueryPreparer subclass that includes access to the LuceneIndex. We can then cast to this subclass within the SearchTupleFunction.
On Friday, 22 July 2016, 12:39, Jacek Grzebyta <grzebyta.dev@xxxxxxxxx> wrote:
TupleFunction is for rdf function and for property functions