[Nepomuk] Refactoring for Soprano 3

[Sebastian Trüg]

On Tuesday 20 October 2009 13:57:10 Leo Sauermann wrote:
> > Question is: do we actually need a close method or is it enough to simply
> > delete the object. The only reason I could think of for a close method is
> > to match an existing isOpen or isConnected method which is necessary.
> 
> All the database apps I used in my programming life had something like
> "close", be it ODBC, JDBC, or Sesame. In
> non-java-garbage-collected-bliss you usually close/dispose objects that
> take memory.
> As a connection can have uncommitted changes, it takes memory.

I actually see Greg's point in that it might be interesting to check the 
status of a closed connection. Thus, adding a close method makes sense after 
all. (Although I doubt anyone will ever use it ;)
 
> >> * dirty reads - the repositoryconnection must support dirty reads of its
> >> own changes in the listStatement AND SPARQL implementations - this is a
> >> major issue in nepomuk-java which I implemented in ClientSession and
> >> diffmodelset, and having dirty reads on your connection-aware changes
> >> with SPARQL support is the best way to go, although the hardest to
> >> achieve. It allows to build nice guis showing the results "as if
> >> commited" while not having commited yet. Note, that dirty reads are very
> >> unlikely to work for text indexing.
> >
> > I think this is up to the backend. Some backends might not support that.
> 
> yep, Sesame is picky to that. But it is nice to have.
> and if different backends behave *differently* each time, you can't use
> the dirty reads reliably and won't benefit from it.
> 
> well, dirty read with SPARQL is a dream of me to have, I don't think the
> backends support it now (didn't look for a year now), so ignore that... :-|
>
> >> * writing to the repository should not invalidate open readers and
> >> queries. It sucks hard when RDF apis suddenly "fail" in a half-iterated
> >> query result when you concurrently do changes. An iterator should be
> >> valid from start to end, despite doing changes to the same
> >> repositoryconnection while the iterator is open. If this is not
> >> supported, it pushes a lot of hassle to the individual developer
> >
> > I think writes should not be possible on a connection with an open
> > iterator/cursor. If an application needs to read and write at the same
> > time it opens two connections, right?
> 
> sounds clunky to me to have two connections open at the same time. but
> alas, so be it. document it!

Well, yes, it is a bit clunky. But as you said: the backends do not support 
it. Thus, it could only be optional which would result in nobody using it 
anyway.

Cheers,
Sebastian