You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rya.apache.org by "Ly, Kiet" <Ki...@finra.org> on 2016/06/14 11:26:23 UTC
RYA-83
I wrote up https://issues.apache.org/jira/browse/RYA-83. Is this a valid issue? It failed on select * where { ?s ?p ?o . }. I tested the this query on Blazegraph and it works correctly.
I used POSTMAN to send in sparql query request against a develop branch build.
Confidentiality Notice:: This email, including attachments, may include non-public, proprietary, confidential or legally privileged information. If you are not an intended recipient or an authorized agent of an intended recipient, you are hereby notified that any dissemination, distribution or copying of the information contained in or transmitted with this e-mail is unauthorized and strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and permanently delete this e-mail, its attachments, and any copies of it immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.
Re: RYA-83
Posted by "Aaron D. Mihalik" <aa...@gmail.com>.
The Spark analogy is a great one and I really like the "limit n" use case.
I think we should aim to implement that use case (and give a useful message
when someone queries without a "limit n").
The only caveat is that is a lot easier said than done. I don't think the
"limit n" is exposed in a useful place in the Sail layer query processing...
--Aaron
On Tue, Jun 14, 2016 at 8:24 AM Ly, Kiet <Ki...@finra.org> wrote:
> It is the same with spark. Call collect() on large dataset will blow up
> the driver. The trick is select * where {} limit n. The use case i wanted
> to check the triples just inserted are there.
>
>
>
>
> From: Puja Valiyil <pu...@gmail.com>>
> Date: Tuesday, Jun 14, 2016, 8:18 AM
> To: dev@rya.incubator.apache.org <dev@rya.incubator.apache.org<mailto:
> dev@rya.incubator.apache.org>>
> Subject: Re: RYA-83
>
> Hi Kiet,
> I've been meaning to post on your ticket. This is a deliberate feature
> for Rya that is intended to avoid inadvertently starting a full table
> scan. Since the data stored in Rya may be extremely large since it is
> intended for cloud based systems, the exception is intentionally thrown.
> It isn't compliant with sparql 1.1 to not support that query, so I'm not
> sure if we should change it or not.
> What does everyone else think?
> Thanks,
> Puja
> Sent from my iPhone
>
> > On Jun 14, 2016, at 7:26 AM, Ly, Kiet <Ki...@finra.org> wrote:
> >
> > I wrote up https://issues.apache.org/jira/browse/RYA-83. Is this a
> valid issue? It failed on select * where { ?s ?p ?o . }. I tested the this
> query on Blazegraph and it works correctly.
> > I used POSTMAN to send in sparql query request against a develop branch
> build.
> >
> > Confidentiality Notice:: This email, including attachments, may include
> non-public, proprietary, confidential or legally privileged information.
> If you are not an intended recipient or an authorized agent of an intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of the information contained in or transmitted with this e-mail is
> unauthorized and strictly prohibited. If you have received this email in
> error, please notify the sender by replying to this message and permanently
> delete this e-mail, its attachments, and any copies of it immediately. You
> should not retain, copy or use this e-mail or any attachment for any
> purpose, nor disclose all or any part of the contents to any other person.
> Thank you.
>
RE: RYA-83
Posted by "Ly, Kiet" <Ki...@finra.org>.
It is the same with spark. Call collect() on large dataset will blow up the driver. The trick is select * where {} limit n. The use case i wanted to check the triples just inserted are there.
From: Puja Valiyil <pu...@gmail.com>>
Date: Tuesday, Jun 14, 2016, 8:18 AM
To: dev@rya.incubator.apache.org <de...@rya.incubator.apache.org>>
Subject: Re: RYA-83
Hi Kiet,
I've been meaning to post on your ticket. This is a deliberate feature for Rya that is intended to avoid inadvertently starting a full table scan. Since the data stored in Rya may be extremely large since it is intended for cloud based systems, the exception is intentionally thrown. It isn't compliant with sparql 1.1 to not support that query, so I'm not sure if we should change it or not.
What does everyone else think?
Thanks,
Puja
Sent from my iPhone
> On Jun 14, 2016, at 7:26 AM, Ly, Kiet <Ki...@finra.org> wrote:
>
> I wrote up https://issues.apache.org/jira/browse/RYA-83. Is this a valid issue? It failed on select * where { ?s ?p ?o . }. I tested the this query on Blazegraph and it works correctly.
> I used POSTMAN to send in sparql query request against a develop branch build.
>
> Confidentiality Notice:: This email, including attachments, may include non-public, proprietary, confidential or legally privileged information. If you are not an intended recipient or an authorized agent of an intended recipient, you are hereby notified that any dissemination, distribution or copying of the information contained in or transmitted with this e-mail is unauthorized and strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and permanently delete this e-mail, its attachments, and any copies of it immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.
Re: RYA-83
Posted by Puja Valiyil <pu...@gmail.com>.
Hi Kiet,
I've been meaning to post on your ticket. This is a deliberate feature for Rya that is intended to avoid inadvertently starting a full table scan. Since the data stored in Rya may be extremely large since it is intended for cloud based systems, the exception is intentionally thrown. It isn't compliant with sparql 1.1 to not support that query, so I'm not sure if we should change it or not.
What does everyone else think?
Thanks,
Puja
Sent from my iPhone
> On Jun 14, 2016, at 7:26 AM, Ly, Kiet <Ki...@finra.org> wrote:
>
> I wrote up https://issues.apache.org/jira/browse/RYA-83. Is this a valid issue? It failed on select * where { ?s ?p ?o . }. I tested the this query on Blazegraph and it works correctly.
> I used POSTMAN to send in sparql query request against a develop branch build.
>
> Confidentiality Notice:: This email, including attachments, may include non-public, proprietary, confidential or legally privileged information. If you are not an intended recipient or an authorized agent of an intended recipient, you are hereby notified that any dissemination, distribution or copying of the information contained in or transmitted with this e-mail is unauthorized and strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and permanently delete this e-mail, its attachments, and any copies of it immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.
Re: RYA-83
Posted by "Aaron D. Mihalik" <aa...@gmail.com>.
We have this query disabled because it would involve a full table scan.
Perhaps we should make this function configurable (an enable this query by
default)?
Thanks for opening the ticket, and I'll add my comment onto the ticket.
--Aaron
On Tue, Jun 14, 2016 at 7:26 AM Ly, Kiet <Ki...@finra.org> wrote:
> I wrote up https://issues.apache.org/jira/browse/RYA-83. Is this a valid
> issue? It failed on select * where { ?s ?p ?o . }. I tested the this query
> on Blazegraph and it works correctly.
> I used POSTMAN to send in sparql query request against a develop branch
> build.
>
> Confidentiality Notice:: This email, including attachments, may include
> non-public, proprietary, confidential or legally privileged information.
> If you are not an intended recipient or an authorized agent of an intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of the information contained in or transmitted with this e-mail is
> unauthorized and strictly prohibited. If you have received this email in
> error, please notify the sender by replying to this message and permanently
> delete this e-mail, its attachments, and any copies of it immediately. You
> should not retain, copy or use this e-mail or any attachment for any
> purpose, nor disclose all or any part of the contents to any other person.
> Thank you.
>