Awesome Can we have some javadoc on the new interfaces please?
Couple of questions since I now need to at least stub these for our internal implementations. Primarily these revolve around how one opts out of dynamic updates since these won't be usable in our environment due to the peculiarities of our hybrid computing architecture. Is it safe/recommended to just throw an exception in methods like createStreaming() of UpdateEngineFactory if your implementation does not support streaming? Some possible slight refactors: UpdateEngineBase implements UpdateEngine and UpdateEngineStreaming - can I suggest that we add an UpdateEngineStreamingBase which adds the UpdateEngineStreaming interface so non-streaming implementations can still just extend UpdateEngineBase. Either that implement UpdateEngineStreaming in UpdateEngineMain not in UpdateEngineBase. The getInsertDataSink() and getDeleteDataSink() on UpdateVisitor seem at odds with a visitor interface, would they not be better off in a separate interface? I see only one usage of these so them being placed there seems somewhat arbitrary. Rob On 1/31/13 4:33 AM, "Stephen Allen" <[email protected]> wrote: >All, > >I've finally completed the work I was doing on streaming SPARQL Updates. >Yay! > >There should be no user visible changes from this update, but there >will be some changes for 3rd party storage engines. Specifically they >need to implement a couple of new methods in their UpdateEngineFactory >implementation. See the changes to >jena-tdb/com.hp.hpl.jena.tdb.modify.UpdateEngineTDB in revision >1440841 to see what probably needs to be done for your engine. > >What this change enables: > 1) Update requests that can contain an unlimited number of queries > 2) Update queries that can contain an unlimited number of quads >inside of INSERT DATA and DELETE DATA queries > 3) If the underlying storage engine is transactional, then Fuseki >can now stream the updates directly to the engine, theoretically >allowing an unlimited number of quads to be inserted in a single >query* > >To exploit these new capabilities to the fullest, you probably need to >use jena-client, which is able create streaming update requests both >for local datasets, and remote HTTP endpoints. > >Please let me know if you notice any problems. As this is a pretty >big feature change, I would appreciate test reports if you have time. > >-Stephen > > >* I believe TDB still buffers uncommitted changes in memory, so there >is still a limit here (but it is a lot better than before, which >stored multiple copies of the update request in memory). You can test >this unlimited feature by using GraphStoreNull, which will just throw >away new quads (use the assembler attached to JENA-330 to stand up a >Fuseki instance using GraphStoreNull).
