As a little background, I have created a custom RowReader that allows me to filter out objects based upon some criteria on that object. More specifically, if a deleted date exist on the object, I filter it out and return null.
The idea behind this is that I want to maintain some history in my database, but not even have the filtered object available to be used outside of OJB. The custom rowreader works pretty well in doing that, except I have run into an issue with Iterators returned from PB, and also internal functions inside of OJB that use these iterators. In my application, I know that the Iterator might have a spot that contains a null object, but the it.hasNext() will return true, because the null object was placed into there. However, there are places inside of OJB where the assumption has been made that an object coming out of an Iterator will always be non-null. This is probably not a bad assumption as you would assume this would never be the case. But, as you can probably tell, what is happening is the Iterator thinks it has a next value, but doesn't really know that it doesn't until the next() method is called, and the RowReader filters it out. A good example of where OJB makes this assumption is in ReferencePrefetcher.associateBatched(). But this is just one of many. Now, I see a couple options: 1)Stop using custom RowReaders, and make it known via documentation that a RowReader must still return a non-null objects, otherwise other code will break 2) Fix all the points in other OJB methods where the assumption is made that a value that comes out the Iterator is not null, and make it do a null-check 3) Change RsIterator.next() to be smater and give the RowReader a chance to filter out the objects. However, the problem with this is if the 'filtered' object exist in the middle of the chain, the rs.next() would return false, and the rest of the non-filtered objects would be lost. I would love to get some thoughts on this. My guess is that number 1 or 2 is the best answers, although 1 seems to be pretty harsh. Thanks -Andrew
