[Nepomuk] Refactoring for Soprano 3

[Leo Sauermann]

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:  leo.sauermann at dfki.de

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
_____________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20091020/07999588/attachment.htm