Re: [Aperture-devel] reportUntouched()

[Grant I. <gsi...@ap...>]

I dug a little more into this, part of it is due to my test not  
clearing out the store between runs.  Thus, I was doing:

1. Create temporary directory and file
2. Crawl both

Run test again with new directory and file.  Thus, Aperture is  
reporting that the old directory and file are untouched, and therefore  
should be removed.

I can see why this results in a removed event, but still not sure  
whether I would want that treated as a remove, or if I wouldn't prefer  
at least having an opportunity to let my app decided instead of  
Aperture deciding for me.  I'll submit a patch for consideration.

As a side note, and take this as purely pragmatic advice for  
maintaining an O/S library "in the wild" and not some religious  
discussion of abstract classes vs. interfaces and perfect OO design,  
etc., but we may want to consider, before releasing 1.0 and being  
committed to certain APIs for back compatibility reasons, switching  
interfaces like CrawlerHandler to be an abstract class.  It will save  
you a lot of headaches when it comes to 1.1, etc. and you want to add  
a method to the class, but can't because you've committed to http://aperture.wiki.sourceforge.net/BackwardsCompability 
  API back-compatibility.  Just a suggestion...  If you want to dig  
into all the gory discussions, go to http://lucene.markmail.org and  
search for "backwards compatibility".

Cheers,
Grant

On Aug 21, 2008, at 5:07 PM, Grant Ingersoll wrote:

> Hi,
>
> Was testing my new persistence stuff and noticed that I was getting
> callbacks to objectRemoved() when I didn't expect them.  Upon
> debugging, I see that they are coming from: reportUntouched():
> protected void reportUntouched() {
> 	    ClosableIterator iter = accessData.getUntouchedIDsIterator();
> 	    while (iter.hasNext()) {
> 	        handler.objectRemoved(this, iter.next().toString());  ////
> HERE
> 	        crawlReport.increaseRemovedCount();
> 	    }
> 		accessData.removeUntouchedIDs();
> 	}
>
>
> Shouldn't this be calling objectNotModified() or some new method named
> objectNotTouched()?  If not, what is the use case where untouched
> means removed and how would I distinguish untouched from removed in
> the callback such that I can deal w/ it the way I need to?
>
> I suppose one workaround is to extend the crawlers used to override
> the reportUntouched(), but I suspect I am missing something in terms
> of how this is intended to be used.
>
> Thanks,
> Grant