You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rya.apache.org by John Smith <jo...@gmail.com> on 2017/01/03 21:01:07 UTC

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

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

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

Posted by David Lotts <dl...@gmail.com>.
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 <jo...@gmail.com> 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 <dl...@gmail.com> 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<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 <jo...@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?*
> > >
> >
>

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

Posted by John Smith <jo...@gmail.com>.
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 <dl...@gmail.com> 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<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 <jo...@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?*
> >
>

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

Posted by David Lotts <dl...@gmail.com>.
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 <jo...@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?*
>