The error is thrown here:
rya/dao/accumulo.rya/src/main/java/org/apache/rya/accumulo/query/AccumuloRyaQueryEngine.java
line 142
````
strategy = ryaContext.retrieveStrategy(stmt);
if (strategy == null) {
throw new IllegalArgumentException("TriplePattern[" +
stmt + "] not supported");
}
````
The strategy is TABLE_LAYOUT and the scan range.
The TABLE_LAYOUT is which table it scans to match the statement pattern:
SPO, POS, or OSP, and
the scan range is a start and stop byte[] range for scanning that table.
Try creating a new strategy and see where that takes you:
1. Copy class SpoWholeRowTriplePatternStrategy to
NullRowTriplePatternStrategy,
/rya.api/src/main/java/org/apache/rya/api/query/strategy/wholerow/SpoWholeRowTriplePatternStrategy.java
2. fix the handle() method so that it returns true for all null parameters,
and
3. replace the defineRange() with this:
defineRange(RyaURI, RyaURI, RyaType, RyaURI,
RdfCloudTripleStoreConfiguration) {
start = new Byte[] { /* empty array */ }; // Scan from the
beginning of the Accumulo table.
stop = LAST_BYTES; // Scan to the end, up through things
beginning with 0xff.
return new RdfCloudTripleStoreUtils.CustomEntry<TABLE_LAYOUT,
ByteRange>(TABLE_LAYOUT.SPO, new ByteRange(start, stop));
}
Then add a new instance of NullRowTriplePatternStrategy in method:
org.apache.rya.api.resolver.RyaTripleContext.addDefaultTriplePatternStrategies(boolean)
And your done!
There might be some oddness about creating a range with an empty start
array. Might be better to skip the range when creating the scanner.
david.
On Tue, Jan 3, 2017 at 4:01 PM, John Smith <[email protected]> wrote:
> *I was looking to make RYA more SPARQL1.1 compliant by enabling the
> capability to perform the following query*
>
> *SELECT * { s? p? o? } *
>
>
>
>
>
> *I found that this capability is already supported, it is simply disabled
> ( RYA-83 <https://issues.apache.org/jira/browse/RYA-83> )Could someone
> point me to where in the code it is disabled?I would be interested in
> better understanding the reasons for disabling this capability. All that
> is said in RYA-83 is that it would perform a full table scan. I suppose
> that could be expensive. But just because a query is expensive is that
> reason enough to prevent someone from issuing the query? What if the user
> is willing to pay the cost of running an expensive query? What are your
> thoughts?*
>
