Re: select * where { s? p? o? } query

[David Lotts]

Way to go John!  That was fast turn around!
We just pulled your pull request so now it is in the Master branch of Rya.
I had some doubts about how it would handle graph-context, but on closer
inspection, that is handled outside of the strategy.

Anything else I can help you fix in Rya?  Feel free to look thru the Jira
issues.
david.

On Wed, Jan 4, 2017 at 6:16 PM, John Smith  wrote:

> Thank you! I got it to work using your suggestion.  Here is a pull request
> with this capability (https://github.com/apache/incubator-rya/pull/136).
> I just had to added this NullRowTriplePatternStrategy to RyaTripleContext
> default triple pattern strategies, so that it is used :)
>
> On Wed, Jan 4, 2017 at 9:21 AM, David Lotts  wrote:
>
> > 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 > 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  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  )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?*
> > >
> >
>

Re: select * where { s? p? o? } query

[John Smith]

Thank you! I got it to work using your suggestion.  Here is a pull request
with this capability (https://github.com/apache/incubator-rya/pull/136).
I just had to added this NullRowTriplePatternStrategy to RyaTripleContext
default triple pattern strategies, so that it is used :)

On Wed, Jan 4, 2017 at 9:21 AM, David Lotts  wrote:

> 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 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  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  )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?*
> >
>

Re: select * where { s? p? o? } query

[David Lotts]

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.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  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  )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?*
>