Wednesday, September 08, 2004

I finished the remove code for the ClosableIterator classes today. I have yet to write unit tests, but the Kowari tests which needed this method are now passing, so it looks promising.

Part of the operation of a Remove involves calling methods which can throw a GraphException. Unfortunately, the remove method does not support throwing any new exception types, so I was forced to resort to a RuntimeException. After much angst I opted for an IllegalStateException, as the exception will only be thrown if the current iterator's index can remove a statement, but a different index cannot.

When I first ran the Kowari tests I discovered that nothing had changed. This is because the code in question was using the following idiom:

  Iterator ci = graph.find(...);

while (ci.hasNext()) {
Triple triple = (Triple);
This was not using the Iterator.remove() method, and it should be evident that it was going to cause ConcurrentModificationExceptions when used on a graph that is base on the java.util collections framework. The change to using Iterator.remove() was trivial, and allowed the test to pass, making KA happy:
  Iterator ci = graph.find(...);

while (ci.hasNext()) {;
However, this caused the Kowari graph implementation to fail the same test, due to an unimplemented Iterator.remove() method. KA was not too happy about that part, and asked if I could fix it.

I mentioned the problem to DM, who pointed out that he went to a lot of effort to make sure that removing triples from a graph with a current iterator would work perfectly. This is where Kowari makes heavy use of all of its micro-phases. Since I have no plans on making JRDFmem completely transactional, with micro-phases to protect each little operation, then I'm happy to let it throw a ConcurrentModificationException instead.

To get it working, I'll probably make use of DM's hard work, and have the Iterator.remove() method call the Graph.remove(Triple) method.

KA helped me set up Eclipse for a Kowari project. It certainly has a lot of features. However, with great features comes great complexity. Even KA was stumped setting much of it up, and he had to refer to his own setup for many items.

By the end of it, it seemed to be building within Eclipse, but there were still a few problems being reported. One of them was a complaint that a file was missing, so I went and tracked it down and added that file. Then I started getting a report saying that file was included more than once. KA didn't know exactly what was going on, so I'm sure I'll be working on this for a while.

No comments: