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 <johns0...@gmail.com> 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?* >