Hi Andy,
Yes. GraphOracleSem and DatasetGraphOracleSem allow addition/deletion of
triples and quads, respectively.
Users can choose to commit or rollback transactions at any time. Without
committing, one session can of course
see its own changes. But other sessions won't.
We will use http://jena.apache.org in our document, if we haven't already done
so :)
Cheers,
Zhe
On 9/4/2013 2:48 PM, Andy Seaborne wrote:
On 04/09/13 17:02, Alan Wu wrote:
Hi Andy,
FYI, Oracle has recently moved to Apache Jena 2.7.2 to align with Top
Quadrant's tools and
customer's applications.
Thanks,
Zhe Wu
Oracle Spatial and Graph
Zhe,
Thanks for the information. It's beginning to look like transaction boundaries
are a significant factor, for example, deleting and adding triples as a signal
ACID action. How's that handled? Via
oracle.spatial.rdf.client.jena.GraphOracleSem?
Andy
PS Hopefully the docuemnt will change http://jena.sourceforge.net/ to
http://jena.apache.org/ as well :-) Your lawyers can advise on the legal side.
On 9/4/2013 2:15 AM, Andy Seaborne wrote:
The Jena project works in public. The history of the discussions for
BulkUpdateHandler and SDB are in various public archives.
I would like to see acknowledgement of prior discussions and the
intentions behind the changes.
We made the graph-level bulk update handler change at 2.10.0 and we've
had 2.10.1 since then.
There was a message on the users list Nov 2012
http://mail-archives.apache.org/mod_mbox/jena-users/201211.mbox/%3C50B660D4.6070306%40apache.org%3E
and the dev list a year ago:
http://mail-archives.apache.org/mod_mbox/jena-dev/201209.mbox/%3C5044E9F3.8060705%40apache.org%3E
Oracle are aware of the changes:
http://mail-archives.apache.org/mod_mbox/jena-users/201211.mbox/%3C50B688D8.9040600%40oracle.com%3E
Oracle do not track Jena versions.
Oracle (at least 11g) is for Jena 2.6.2 (2009-10-16)
http://docs.oracle.com/cd/E18283_01/appdev.112/e11828/sem_jena.htm
I do know that the complexities arising in Jena lead to costs for
storage implementers. I want to reduce those costs in the long term.
Andy