Re: Update

Hi Tim,

see http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201009.mbox/%3cAANLkTiknhwnesimUKj+2t6bXzyX2NXPZCUt2hBKzigdr@mail.gmail.com%3e for a medium/long term solution for the locking issue.

Pre-caching is not a solution as the iterator can be very long. In fact some storage providers used to use pre-caching but this yields to memory problems as soon as the apps where dealing with real world data.

As Henry allready mentioned collectediter is an implementations that switches to pre-cached mode transparently when a concurrent-modification exeption occurs, is is typically used in scala server pages where the amount of data in the itertor is small and developers don't care about locking.

The triplecollection itself is iterable, but filter returns an iterator. Maybe add another method (subgraph ?) that returns an iterable triplecollection containing the matching triples.

cheers,
reto

----- Original message -----
> I was telling My friend Tim Boudreau from the Netbeans project about 
> Clerezza as he was looking for something to do for his between job 
> holiday.
> 
> Here's an e-mail he sent which I thought would be better forwarded 
> to the list, to avoid all that good writing getting lost.
> 
> 
> On 13 May 2011, at 10:54, Tim Boudreau wrote:
> 
> > From a quick look at the FAQ, here's a quick API thought:
> > 
> > This sort of thing (IMO anything that forces developers to remember
> > writing finally blocks) is evil (I know, you see it everywhere in Java
> > - it's still evil):
> > 
> > Lock l = mGraph.getLock().readLock();
> > l.lock();
> > try {
> > Iterator<Triple> iter = mGraph.filter(...);
> > //iterate over triples
> > } finally {
> > l.unlock();
> > }
> > 
> > My first thought is, unless the collections are prohibitively large,
> > make a copy and simply eliminate this problem (most developers forget
> > that doing
> > new HashSet(someCollection);
> > or similar also involves iterating someCollection under the hood, so
> > you end up with bugs anyway).
> > 
> > If the lock is really unavoidable, the following is a much nicer
> > pattern that takes care of the lock without having to bother the
> > caller about it:
> > 
> > interface CollectionUser {
> > <T> T withCollection (Collection c);
> > }
> > 
> > and put a method on whatever object you'd get the collection from,
> > which takes care of acquiring the lock, doing whatever is necessary,
> > and then releasing it, e.g.
> > 
> > public <T> T useCollection(CollectionUser<T> u) {
> > Lock l = mGraph.getLock().readLock();
> > l.lock();
> > try {
> > return u.withCollection(getTheCollection());
> > } finally {
> > l.unlock();
> > }
> > }
> > 
> > Then everybody's code is guaranteed-correct and nobody has to think
> > about locks.
> > 
> > You could generify it as
> > interface CollectionUser<T, R extends Iterable<T>> {
> > public <A> A withCollection(R collection);
> > }
> > 
> > although sometimes people find too-generic things confusing, so it may
> > be best to leave some of that out and make it specific to the
> > collection type if that is known.
> > 
> > BTW, it's probably nicer to return Iterable rather than Iterator,
> > since then the caller can use the nice for-loop syntax:
> > for (Thing t : theIterable) { ... }
> > 
> > -Tim
> 
> 
> Tim, that's why we need you on the list. :-)
> 
> Scala also provides a lot of power tools to get rid of this. I think the
> RichGraphNode
> 
> https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/rdf.scala.utils/src/main/scala/org/apache/clerezza/rdf/scala/utils/RichGraphNode.scala
> 
> It calls a CollectedIter which hides some of that
> 
> https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/rdf.scala.utils/src/main/scala/org/apache/clerezza/rdf/scala/utils/CollectedIter.scala
> 
> But I think one can do a lot better as Scala supports closures and many
> other goodies we have been waiting for in java for a while. It's just
> not something I have had time to look at.
> 
> In any case there is a lot of improvement to do in Clerezza. But it is a
> very   original and interesting project to look at.
> 
> Henry
> 
> Social Web Architect
> http://bblfish.net/
> 
>