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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
