Re: GraphXGraphGenerator Usage Help

[Puja Valiyil]

Yes, you need to install the iterator on the accumulo servers.
The iterator jar should be produced by the indexing project-- I can send
more detailed instructions if the read mes don't have any thing useful.

On Tuesday, January 10, 2017, John Smith  wrote:

> I can run the example, but when I try to use a live instance of accumulo
> (1.8) it throws a ClassNotFoundException
> DocumentIndexIntersectingIterator.java.  It seems like the
> GraphxGraphGenerator is built against Accumulo 1.6.4, and even the test
> doesn't seem to work if I bump it up to 1.8.  I wonder if this is an issue
> with the latest version of Accumulo not being supported by Rya?  I find it
> strange that Accumulo complains about not being able to find the
> DocumentIndexIntersectingIterator.java class since it is a Rya class and
> not an accumulo class.. do i need to install (some kind of) a Rya addon to
> Accumulo for this to work?
>
> On Mon, Jan 9, 2017 at 7:39 PM, Puja Valiyil  > wrote:
>
> > Hi John,
> > It's not possible to use the core Rya indices to support the graphx api--
> > there is a requirement for uniqueness in vertices that is not possible to
> > support using the core indices.   To support graphx efficiently, all of
> the
> > assertions on a node of the graph must be stored on a single accumulo row
> > (so you can guarantee all of the assertions will be stored on a single
> > accumulo tablet).  The core Rya indices do not support this requirement,
> > but the entity centric index does.
> > There is a configuration parameter to enable the entity centric index.
> You
> > can see how to enable it by looking at the entity centric example in the
> > examples project-- let me know if you have trouble finding it.
> >
> > On Monday, January 9, 2017, John Smith  > wrote:
> >
> > > I'm trying to use the GraphXGraphGenerator class but it is hard coded
> to
> > > use the EntityCentricIndex table by default.  But this doesn't exist in
> > Rya
> > > by default.  Shouldn't this default to the SPO table?  Or perhaps even
> > > better, be a configurable parameter?  What is the purpose of the
> > > EntityCentricIndex ?  How do I enable it?
> > >
> >
>

Re: GraphXGraphGenerator Usage Help

[John Smith]

I can run the example, but when I try to use a live instance of accumulo
(1.8) it throws a ClassNotFoundException
DocumentIndexIntersectingIterator.java.  It seems like the
GraphxGraphGenerator is built against Accumulo 1.6.4, and even the test
doesn't seem to work if I bump it up to 1.8.  I wonder if this is an issue
with the latest version of Accumulo not being supported by Rya?  I find it
strange that Accumulo complains about not being able to find the
DocumentIndexIntersectingIterator.java class since it is a Rya class and
not an accumulo class.. do i need to install (some kind of) a Rya addon to
Accumulo for this to work?

On Mon, Jan 9, 2017 at 7:39 PM, Puja Valiyil  wrote:

> Hi John,
> It's not possible to use the core Rya indices to support the graphx api--
> there is a requirement for uniqueness in vertices that is not possible to
> support using the core indices.   To support graphx efficiently, all of the
> assertions on a node of the graph must be stored on a single accumulo row
> (so you can guarantee all of the assertions will be stored on a single
> accumulo tablet).  The core Rya indices do not support this requirement,
> but the entity centric index does.
> There is a configuration parameter to enable the entity centric index.  You
> can see how to enable it by looking at the entity centric example in the
> examples project-- let me know if you have trouble finding it.
>
> On Monday, January 9, 2017, John Smith  wrote:
>
> > I'm trying to use the GraphXGraphGenerator class but it is hard coded to
> > use the EntityCentricIndex table by default.  But this doesn't exist in
> Rya
> > by default.  Shouldn't this default to the SPO table?  Or perhaps even
> > better, be a configurable parameter?  What is the purpose of the
> > EntityCentricIndex ?  How do I enable it?
> >
>

Re: rya parser failed on parsing large numeric type

[David Lotts]

> RDF parser confused between large numeric data type with integer. Any
work around for this?  This is a recent build from master branch 3.2.10 I
think.

This issue is reported here: https://issues.apache.org/jira/browse/RYA-43

This has a mechanically simple fix, but it breaks existing
implementations.  So making it backward compatible is probably why it has
not been done yet.  Backward compatible can be done by designing a way to
mix the encoding from LexiTypeEncoders.bigIntegerEncoder() with the
existing LexiTypeEncoders.integerEncoder().  Or create a new Lexical
encoder, that handles both, or maybe upgrade utility to modify the data.

So you could do this as a work around in your own code if you have luxury
of starting from an empty Rya repo:

Copy
/rya.api/src/main/java/org/apache/rya/api/resolver/impl/IntegerRyaTypeResolver.java
to LittleIntegerRyaTypeResolver.java

Then, in IntegerRyaTypeResolver.java, where-ever it uses a Integer, replace
with a BigInteger.
Replace LexiTypeEncoders.integerEncoder()  with
LexiTypeEncoders.bigIntegerEncoder()

https://github.com/calrissian/mango/blob/master/mango-core/src/main/java/org/calrissian/mango/types/encoders/lexi/BigIntegerEncoder.java

Test and done!

david.

rya parser failed on parsing large numeric type

[Ly, Kiet]

RDF parser confused between large numeric data type with integer. Any work 
around for this?
This is a recent build from master branch 3.2.10 I think.

Caused by: java.lang.NumberFormatException: For input string: 
"-6703205597155942197"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:583)
at java.lang.Integer.parseInt(Integer.java:615)
at 
org.apache.rya.api.resolver.impl.IntegerRyaTypeResolver.serializeData(IntegerRyaTypeResolver.java:48)

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.