It was Sebastian Trüg who said at the right time 20.10.2009 12:43 the following words: > On Thursday 15 October 2009 21:51:24 Leo Sauermann wrote: > >> Hi Sebastian, >> >> from my experience: >> > >> * close/disconnect/dispose (however you put it). A repository connection >> must be explicitly closed. >> > > 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.
> >> * 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! >> I have no time for discussions, please take the input as is. >> > > :P > well, seems I did have time. ok, back to the next telco now ... 8-] best Leo -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: [email protected] Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
