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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> >> 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 >> > >> > >
