Any reason SELECTing on a predicate wouldn't be working? about arc2 HOT 6 OPEN

Hi @craigdietrich, can you provide us a working exploit of the problem? A minimal graph + the code you use to query the database would be helpful.

from arc2.

Thanks for your quick reply, @k00ni! I'll put together an example and get back to you soon.

from arc2.

Following up on this, I think I figured out the problem. All of our ARC2 databases were created a number of year ago, even through we've updated the libraries along the way (currently at the most recent release).

It looks like in some of the databases, the id2val table has thousands of rows -- each time a triple is entered it appears that a new entry is added for the predicate even if that predicate already exists

In some of the databases, the number of rows in the id2val table is, say, 100 -- each time a triple is added it re-uses the predicate if it exists.

For the former, I'm not able to query on the predicate because the temp table query is asking for a specific predicate ID, even though there might be hundreds of IDs for a given predicate

For the latter, it works a-okay because there's only one ID per predicate.

I suppose at this stage we can work around this (we only have one client hoping to take advantage of the work we're doing that needs to query on predicates), and I think their DB is the latter. Though, I'm curious if anyone has thoughts on why the former databases had that runaway predicate creation? Curious your thoughts?

from arc2.

I observed similar behavior when i worked on version 2.4 but can't help you with an explanation.

Maybe the following can help here:

1. export all triples,
2. setup the database again using our latest database schema (preferably InnoDb instead of MyISAM) and
3. import all triples again.

That might not fix possible buggy behavior, but at least the DB schema is stable and ruled out as the source of the problem.

from arc2.

@k00ni I was thinking the same thing!

I'm more and more thinking that this issue is related to my other, #135 , because the false positive when asking if the val_hash exists would be impactful on id2val, if id2val was relying on val_hash to see if existing predicates existed.

Is there an easy way ti export all triples and import (ie, a built-in way) that you know of? Otherwise, I suppose I'll write a little tool to do it.

Thanks!

from arc2.

Alrighty, this is definitely related to #135 .. I found what I think is another error that was keeping existing predicates from being pulled from id2val.

I'll get both those changes set up in the update fork you created so it can be vetted.

(I still need to figure out a mini tool to export / import the triples, but, I think this should probably be easy enough.)

from arc2.