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/17 17:20:15 UTC
On Storing Rya Metadata in the rya_spo table.
When I perform a scan of the rya_spo table after adding a SINGLE triple, I
see that Rya adds TWO triples, the one I wanted to add and one denoting the
version of Rya. e.g.
rya_spo> scan
INSERT DATA { <http://acme.com/people/Mike> <http://acme.com/actions/likes>
<http://acme.com/people/John> . }
rya_spo> scan
http://acme.com/people/Mike\x00http://acme.com/actions/likes\x00http://acme.com/people/John\x01\x02
: []
urn:org.apache.rya/2012/05#rts\x00urn:org.apache.rya/2012/05#version\x003.0.0\x01\x03
: []
I suppose keeping track of metadata about the version of Rya that was used
to persist data into Accumulo is useful, but shouldn't this metadata be
stored in a different table? (like a metadata table, or something?). I
imagine users will be surprised if triples they didn't add appear in their
store, and surprising users is a code smell. What are your thoughts?
Re: On Storing Rya Metadata in the rya_spo table.
Posted by Puja Valiyil <pu...@gmail.com>.
Even with rya details enabled, the version triple will be added (for backwards compatibility). I'm confused over why this is an issue-- it's a single triple in a triple store that's intended to scale to millions if not billions.
Sent from my iPhone
> On Jan 17, 2017, at 1:19 PM, Chilton, Kevin <Ke...@parsons.com> wrote:
>
> It was checked into 3.2.10. I don't recall if the Rya Details stuff is enabled by default or if it works without using the rya shell to manage your instance. I thought we had a jira ticket relating to version statement, but I'm unable to find it.
>
> - Kevin
>
> -----Original Message-----
> From: benkapp@gmail.com [mailto:benkapp@gmail.com] On Behalf Of John Smith
> Sent: Tuesday, January 17, 2017 1:03 PM
> To: dev@rya.incubator.apache.org
> Subject: Re: On Storing Rya Metadata in the rya_spo table.
>
> This occurs when using the latest from git 3.2.11-SNAPSHOT. What commit fixed this?
>
> On Tue, Jan 17, 2017 at 9:50 AM, Chilton, Kevin <Ke...@parsons.com>
> wrote:
>
>> Newer versions of Rya use the Rya Details table to keep track of this
>> sort of metadata.
>>
>> - Kevin
>>
>> -----Original Message-----
>> From: benkapp@gmail.com [mailto:benkapp@gmail.com] On Behalf Of John
>> Smith
>> Sent: Tuesday, January 17, 2017 12:20 PM
>> To: dev@rya.incubator.apache.org
>> Subject: On Storing Rya Metadata in the rya_spo table.
>>
>> When I perform a scan of the rya_spo table after adding a SINGLE
>> triple, I see that Rya adds TWO triples, the one I wanted to add and
>> one denoting the version of Rya. e.g.
>>
>> rya_spo> scan
>>
>> INSERT DATA { <https://urldefense.proofpoint.com/v2/url?u=http->
>> 3A__acme.com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
>> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
>> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
>> g&s=Qj2CE5OU2Kd7J_TI_vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense&d=CwI
>> BaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIc
>> nBCmOspnR-2OEdiXfx4UDEJmU&m=SHqD37o_I0gFPdBJZdwfZQlV5D4jx-yOkpvUN8VrXv
>> A&s=ybwFRz7voHFDUzHzxHMgAXeocmXjJh_nl_gS50iRjc8&e= .>
>> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
>> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
>> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
>> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEB
>> oTm9 Oxo&e= > <https://urldefense.proofpoint.com/v2/url?u=http->
>> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
>> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
>> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
>> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= > . }
>>
>> rya_spo> scan
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.
>> com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10
>> &r=
>> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
>> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=Qj2CE5OU2Kd7J_TI_
>> vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= \x00https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=SHqD37o_I0gFPdBJZdwfZQlV5D4jx-yOkpvUN8VrXvA&s=ybwFRz7voHFDUzHzxHMgAXeocmXjJh_nl_gS50iRjc8&e= .
>> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
>> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
>> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
>> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEB
>> oTm9 Oxo&e= \x00https://urldefense.proofpoint.com/v2/url?u=http-
>> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
>> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
>> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
>> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= \x01\x02
>> : []
>> urn:org.apache.rya/2012/05#rts\x00urn:org.apache.rya/
>> 2012/05#version\x003.0.0\x01\x03
>> : []
>>
>>
>> I suppose keeping track of metadata about the version of Rya that was
>> used to persist data into Accumulo is useful, but shouldn't this
>> metadata be stored in a different table? (like a metadata table, or
>> something?). I imagine users will be surprised if triples they didn't
>> add appear in their store, and surprising users is a code smell. What are your thoughts?
>>
Re: On Storing Rya Metadata in the rya_spo table.
Posted by John Smith <jo...@gmail.com>.
Also if you have two instances of Rya (because your doing say A/B
development for example) and you upgrade one of them and then you want to
transfer the triples from the older version to the newer version, then you
would get the old version and the new version in your store.
Also if you have a Single Accumulo cluster, but multiple clients, if at any
point a user upgrades their client, and does a direct write to Accumulo,
instead of via the web API, then we would again have two (or more) versions
in our Rya Store.
Such are some of the difficulties with this scheme.
---
Kevin Chilton I think I see what you were talking about
AccumuloRyaInstanceDetailsRepository (
https://github.com/apache/incubator-rya/blob/master/dao/accumulo.rya/src/main/java/org/apache/rya/accumulo/instance/AccumuloRyaInstanceDetailsRepository.java
)
When I add data to Rya it runs through this class and throws a
TableNotFoundException.
So it would seem it most definitely is not enabled by default. Is there a
flag I need to set to enable it or something?
I'm thinking it would make sense to refactor the "rya_instance_details"
table into the "rya_meta_data" table and we add this to our
TableLayoutStrategy, that way we can create this table the same way we make
the other tables, and going forward we can say that we ought to push and
pull all our system specific meta data from there, and we could put in a
ticket to refactor our current codebase to be inline with this philosophy.
Would this make sense?
On Tue, Jan 17, 2017 at 1:52 PM, John Smith <jo...@gmail.com> wrote:
> I can find it with this query
>
> select * {
> <urn:org.apache.rya/2012/05#rts> ?p ?o .
>
> }
>
>
> I also get it when I load the graph into GraphX, since it pulls the entire
> graph.
>
>
> Being but a single triple it isn't a huge deal, but we are establishing
> the precedent that metadata about the implementation details of our store
> is to be intermixed with the users data, and intermixing user data with
> implementation specific details seems like a bad idea. What if a
> (malicious?) user wanted to store triples that talk about older versions of
> Rya? They could insert the triple e.g.
>
> INSERT DATA { <urn:org.apache.rya/2012/05#rts> <urn:org.apache.rya/2012/
> 05#version> "1.0.0" . }
>
> And now our system would have the fact that it is both version 3.0.0 and
> 1.0.0. I imagine that could cause problems.
>
>
>
> On Tue, Jan 17, 2017 at 1:18 PM, David Lotts <dl...@gmail.com> wrote:
>
>> >> When I perform a scan of the rya_spo table after adding a SINGLE
>> triple,
>> I
>> >> see that Rya adds TWO triples, the one I wanted to add and one denoting
>> the
>> >> version of Rya. e.g.
>>
>> Can you see the triple via Sparql?
>> This gets amplified now that we support "select * where {?s ?p ?o. }"
>>
>> Elsewhere, this is done with built-in functions:
>>
>> select ( system:version() )
>>
>> For example:
>> https://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/
>> VirtCheckSvrVersionViaSparql
>>
>> Pro's:
>> All the SQL databases that I know of have system metadata tables. You
>> don't see them unless you specify the table name.
>> Because SQL tables and RDF name spaces have some similarities, in the same
>> way, metadata is scoped and out of the way of applications.
>> Also inference gives you triples that you did not add. So it's a "don't
>> ask for what you don't want" kind of assumption.
>>
>> But I'm not an authority.
>>
>> Code is here:
>>
>> https://github.com/apache/incubator-rya/blob/master/common/
>> rya.api/src/main/java/org/apache/rya/api/domain/RyaSchema.java
>>
>> The subject: *urn:org.apache.rya/2012/05#*
>> is not a valid URI. The possible strings that follow "urn:" are
>> registered
>> by IANA
>> <http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml> --
>> the
>> urn namespace. If you want to roll your own, use a URL (http:...) or a
>> the
>> "tag" URI scheme, described here: https://tools.ietf.org/html/rfc4151 .
>> Tags look like this: *tag:rya.apache.org
>> <http://rya.apache.org>,2017:details#version*
>>
>> david.
>>
>> On Tue, Jan 17, 2017 at 1:19 PM, Chilton, Kevin <
>> Kevin.Chilton@parsons.com>
>> wrote:
>>
>> > It was checked into 3.2.10. I don't recall if the Rya Details stuff is
>> > enabled by default or if it works without using the rya shell to manage
>> > your instance. I thought we had a jira ticket relating to version
>> > statement, but I'm unable to find it.
>> >
>> > - Kevin
>> >
>>
>
>
Re: On Storing Rya Metadata in the rya_spo table.
Posted by John Smith <jo...@gmail.com>.
I can find it with this query
select * {
<urn:org.apache.rya/2012/05#rts> ?p ?o .
}
I also get it when I load the graph into GraphX, since it pulls the entire
graph.
Being but a single triple it isn't a huge deal, but we are establishing the
precedent that metadata about the implementation details of our store is to
be intermixed with the users data, and intermixing user data with
implementation specific details seems like a bad idea. What if a
(malicious?) user wanted to store triples that talk about older versions of
Rya? They could insert the triple e.g.
INSERT DATA { <urn:org.apache.rya/2012/05#rts> <urn:org.apache.rya/2012/05#
version> "1.0.0" . }
And now our system would have the fact that it is both version 3.0.0 and
1.0.0. I imagine that could cause problems.
On Tue, Jan 17, 2017 at 1:18 PM, David Lotts <dl...@gmail.com> wrote:
> >> When I perform a scan of the rya_spo table after adding a SINGLE triple,
> I
> >> see that Rya adds TWO triples, the one I wanted to add and one denoting
> the
> >> version of Rya. e.g.
>
> Can you see the triple via Sparql?
> This gets amplified now that we support "select * where {?s ?p ?o. }"
>
> Elsewhere, this is done with built-in functions:
>
> select ( system:version() )
>
> For example:
> https://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/
> VirtCheckSvrVersionViaSparql
>
> Pro's:
> All the SQL databases that I know of have system metadata tables. You
> don't see them unless you specify the table name.
> Because SQL tables and RDF name spaces have some similarities, in the same
> way, metadata is scoped and out of the way of applications.
> Also inference gives you triples that you did not add. So it's a "don't
> ask for what you don't want" kind of assumption.
>
> But I'm not an authority.
>
> Code is here:
>
> https://github.com/apache/incubator-rya/blob/master/
> common/rya.api/src/main/java/org/apache/rya/api/domain/RyaSchema.java
>
> The subject: *urn:org.apache.rya/2012/05#*
> is not a valid URI. The possible strings that follow "urn:" are registered
> by IANA
> <http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml> --
> the
> urn namespace. If you want to roll your own, use a URL (http:...) or a the
> "tag" URI scheme, described here: https://tools.ietf.org/html/rfc4151 .
> Tags look like this: *tag:rya.apache.org
> <http://rya.apache.org>,2017:details#version*
>
> david.
>
> On Tue, Jan 17, 2017 at 1:19 PM, Chilton, Kevin <Kevin.Chilton@parsons.com
> >
> wrote:
>
> > It was checked into 3.2.10. I don't recall if the Rya Details stuff is
> > enabled by default or if it works without using the rya shell to manage
> > your instance. I thought we had a jira ticket relating to version
> > statement, but I'm unable to find it.
> >
> > - Kevin
> >
>
Re: On Storing Rya Metadata in the rya_spo table.
Posted by David Lotts <dl...@gmail.com>.
>> When I perform a scan of the rya_spo table after adding a SINGLE triple,
I
>> see that Rya adds TWO triples, the one I wanted to add and one denoting
the
>> version of Rya. e.g.
Can you see the triple via Sparql?
This gets amplified now that we support "select * where {?s ?p ?o. }"
Elsewhere, this is done with built-in functions:
select ( system:version() )
For example:
https://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtCheckSvrVersionViaSparql
Pro's:
All the SQL databases that I know of have system metadata tables. You
don't see them unless you specify the table name.
Because SQL tables and RDF name spaces have some similarities, in the same
way, metadata is scoped and out of the way of applications.
Also inference gives you triples that you did not add. So it's a "don't
ask for what you don't want" kind of assumption.
But I'm not an authority.
Code is here:
https://github.com/apache/incubator-rya/blob/master/common/rya.api/src/main/java/org/apache/rya/api/domain/RyaSchema.java
The subject: *urn:org.apache.rya/2012/05#*
is not a valid URI. The possible strings that follow "urn:" are registered
by IANA
<http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml> -- the
urn namespace. If you want to roll your own, use a URL (http:...) or a the
"tag" URI scheme, described here: https://tools.ietf.org/html/rfc4151 .
Tags look like this: *tag:rya.apache.org
<http://rya.apache.org>,2017:details#version*
david.
On Tue, Jan 17, 2017 at 1:19 PM, Chilton, Kevin <Ke...@parsons.com>
wrote:
> It was checked into 3.2.10. I don't recall if the Rya Details stuff is
> enabled by default or if it works without using the rya shell to manage
> your instance. I thought we had a jira ticket relating to version
> statement, but I'm unable to find it.
>
> - Kevin
>
RE: On Storing Rya Metadata in the rya_spo table.
Posted by "Chilton, Kevin" <Ke...@parsons.com>.
It was checked into 3.2.10. I don't recall if the Rya Details stuff is enabled by default or if it works without using the rya shell to manage your instance. I thought we had a jira ticket relating to version statement, but I'm unable to find it.
- Kevin
-----Original Message-----
From: benkapp@gmail.com [mailto:benkapp@gmail.com] On Behalf Of John Smith
Sent: Tuesday, January 17, 2017 1:03 PM
To: dev@rya.incubator.apache.org
Subject: Re: On Storing Rya Metadata in the rya_spo table.
This occurs when using the latest from git 3.2.11-SNAPSHOT. What commit fixed this?
On Tue, Jan 17, 2017 at 9:50 AM, Chilton, Kevin <Ke...@parsons.com>
wrote:
> Newer versions of Rya use the Rya Details table to keep track of this
> sort of metadata.
>
> - Kevin
>
> -----Original Message-----
> From: benkapp@gmail.com [mailto:benkapp@gmail.com] On Behalf Of John
> Smith
> Sent: Tuesday, January 17, 2017 12:20 PM
> To: dev@rya.incubator.apache.org
> Subject: On Storing Rya Metadata in the rya_spo table.
>
> When I perform a scan of the rya_spo table after adding a SINGLE
> triple, I see that Rya adds TWO triples, the one I wanted to add and
> one denoting the version of Rya. e.g.
>
> rya_spo> scan
>
> INSERT DATA { <https://urldefense.proofpoint.com/v2/url?u=http->
> 3A__acme.com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=Qj2CE5OU2Kd7J_TI_vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense&d=CwI
> BaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIc
> nBCmOspnR-2OEdiXfx4UDEJmU&m=SHqD37o_I0gFPdBJZdwfZQlV5D4jx-yOkpvUN8VrXv
> A&s=ybwFRz7voHFDUzHzxHMgAXeocmXjJh_nl_gS50iRjc8&e= .>
> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEB
> oTm9 Oxo&e= > <https://urldefense.proofpoint.com/v2/url?u=http->
> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= > . }
>
> rya_spo> scan
> https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.
> com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10
> &r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=Qj2CE5OU2Kd7J_TI_
> vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= \x00https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=SHqD37o_I0gFPdBJZdwfZQlV5D4jx-yOkpvUN8VrXvA&s=ybwFRz7voHFDUzHzxHMgAXeocmXjJh_nl_gS50iRjc8&e= .
> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEB
> oTm9 Oxo&e= \x00https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= \x01\x02
> : []
> urn:org.apache.rya/2012/05#rts\x00urn:org.apache.rya/
> 2012/05#version\x003.0.0\x01\x03
> : []
>
>
> I suppose keeping track of metadata about the version of Rya that was
> used to persist data into Accumulo is useful, but shouldn't this
> metadata be stored in a different table? (like a metadata table, or
> something?). I imagine users will be surprised if triples they didn't
> add appear in their store, and surprising users is a code smell. What are your thoughts?
>
Re: On Storing Rya Metadata in the rya_spo table.
Posted by John Smith <jo...@gmail.com>.
This occurs when using the latest from git 3.2.11-SNAPSHOT. What commit
fixed this?
On Tue, Jan 17, 2017 at 9:50 AM, Chilton, Kevin <Ke...@parsons.com>
wrote:
> Newer versions of Rya use the Rya Details table to keep track of this sort
> of metadata.
>
> - Kevin
>
> -----Original Message-----
> From: benkapp@gmail.com [mailto:benkapp@gmail.com] On Behalf Of John Smith
> Sent: Tuesday, January 17, 2017 12:20 PM
> To: dev@rya.incubator.apache.org
> Subject: On Storing Rya Metadata in the rya_spo table.
>
> When I perform a scan of the rya_spo table after adding a SINGLE triple, I
> see that Rya adds TWO triples, the one I wanted to add and one denoting the
> version of Rya. e.g.
>
> rya_spo> scan
>
> INSERT DATA { <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__acme.com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=Qj2CE5OU2Kd7J_TI_vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= > <https://urldefense.
> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEBoTm9
> Oxo&e= > <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= > . }
>
> rya_spo> scan
> https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.
> com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=Qj2CE5OU2Kd7J_TI_
> vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= \x00https://urldefense.
> proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=
> CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=
> F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-
> pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEBoTm9
> Oxo&e= \x00https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_
> LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-
> 2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNK
> g&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= \x01\x02
> : []
> urn:org.apache.rya/2012/05#rts\x00urn:org.apache.rya/
> 2012/05#version\x003.0.0\x01\x03
> : []
>
>
> I suppose keeping track of metadata about the version of Rya that was used
> to persist data into Accumulo is useful, but shouldn't this metadata be
> stored in a different table? (like a metadata table, or something?). I
> imagine users will be surprised if triples they didn't add appear in their
> store, and surprising users is a code smell. What are your thoughts?
>
RE: On Storing Rya Metadata in the rya_spo table.
Posted by "Chilton, Kevin" <Ke...@parsons.com>.
Newer versions of Rya use the Rya Details table to keep track of this sort of metadata.
- Kevin
-----Original Message-----
From: benkapp@gmail.com [mailto:benkapp@gmail.com] On Behalf Of John Smith
Sent: Tuesday, January 17, 2017 12:20 PM
To: dev@rya.incubator.apache.org
Subject: On Storing Rya Metadata in the rya_spo table.
When I perform a scan of the rya_spo table after adding a SINGLE triple, I see that Rya adds TWO triples, the one I wanted to add and one denoting the version of Rya. e.g.
rya_spo> scan
INSERT DATA { <https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=Qj2CE5OU2Kd7J_TI_vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= > <https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEBoTm9Oxo&e= > <https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= > . }
rya_spo> scan
https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.com_people_Mike&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=Qj2CE5OU2Kd7J_TI_vbvn8rBQ9H9kNRCV5rIb6LIQ_g&e= \x00https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.com_actions_likes&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=7nLrYW2h4_TJLRGsknwSLElEiU0rOWCq0aEBoTm9Oxo&e= \x00https://urldefense.proofpoint.com/v2/url?u=http-3A__acme.com_people_John&d=CwIBaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=F2yL1qtCQ_8QkxBRIcnBCmOspnR-2OEdiXfx4UDEJmU&m=qONz3ysNOVB-pj5N34NddggiKS8dEp1lW3dleNbPNKg&s=JQhITAdCx3R_9eu35E5N-aIdUBEtseYBtZ5NNdZqkuA&e= \x01\x02
: []
urn:org.apache.rya/2012/05#rts\x00urn:org.apache.rya/2012/05#version\x003.0.0\x01\x03
: []
I suppose keeping track of metadata about the version of Rya that was used to persist data into Accumulo is useful, but shouldn't this metadata be stored in a different table? (like a metadata table, or something?). I imagine users will be surprised if triples they didn't add appear in their store, and surprising users is a code smell. What are your thoughts?