Change to Triples.goTo(pos) leads to wrong results

[RubenVerborgh]

It seems that de30539 breaks functionality. I discovered this when trying to update HDT-Node to v1.2.0, which includes de30539.

The unit test which searches for the pattern ex:s2 null null also returns triples with ex:s1 as a subject: https://travis-ci.org/RubenVerborgh/HDT-Node/jobs/268181699#L611

@MarioAriasGa What was the rationale behind the change?
Are we sure it needed to be absolute? What does that fix?
Should it be reverted or should code in other places be adjusted?

[MarioAriasGa]

The parameter goTo() was originally meant to be absolute and is used from the HDT-it GUI when scrolling the list of triples. I now see that the ObjectIterator is wrong as well and I didn't change it in that commit.

I suggest leaving goTo() absolute, and adding a skip(amount) method to the iterator and using that instead from HDT-node.

[RubenVerborgh]

Thanks!

I now see that the ObjectIterator is wrong as well and I didn't change it in that commit.

I see, could you start a fix/goto branch or similar and create a PR, so we can track for there?

Can you check whether anything else in the source code depends on goTo?

I suggest leaving goTo() absolute, and adding a skip(amount) method to the iterator and using that instead from HDT-node.

For me, it's the same what HDT-Node uses. The issue was that functionality unrelated to goTo also broke.

Can you let me know then what I should be calling to set an offset?

[RubenVerborgh]

Resolved by #89.