So UpdateAction, UpdateExecutionFactory, UpdateProcessor, UpdateProcessorStreaming are part of the user API and should not have changed much. They are the way to interact with the update system. For storage engine implementers, what has changed is that UpdateEngine is now stream based. If, as a storage provider, you for some reason cannot process updates in a streaming fashion, then you may simply buffer up all of the update operations and then do something with them. I've added an example of how to do that with the UpdateEngineNonStreaming class.
UpdateAction was a little screwy, it was basically doing the work that UpdateProcessorBase should have been doing. I've simplified that bit a bunch. Let me know if you still have questions about how to implement an UpdateEngine for your purposes. I will also be going through and pulling out the initial binding as recommended by Andy, so there will still be more changes to UpdateEngine and UpdateEngineFactory. -Stephen On Tue, Feb 5, 2013 at 12:33 PM, Rob Vesse <[email protected]> wrote: > Actually part of my email was still valid, UpdateAction.execute() would > not have fallen back to non-streaming, should now do this as of my latest > commit > > Rob > > > On 2/5/13 9:19 AM, "Rob Vesse" <[email protected]> wrote: > >>Ignore my last email, having problems with Eclipse auto-complete and >>workspace versioning sync issues, also my jet lagged brain having flown >>back into the US only yesterday ;) >> >>Garghhh >> >>Rob >> >> >>On 2/5/13 9:16 AM, "Rob Vesse" <[email protected]> wrote: >> >>>Ok I am slightly stumped by the latest changes >>> >>>UpdateAction.execute() is broken in that it only tries to do streaming >>>updates and can't fall back to non-streaming. >>> >>>UpdateProcessor no longer has any execute() method so is the assumption >>>simply that the update happens when startRequest() is called or when >>>finishRequest() is called???? >>> >>>We will only ever be using non-streaming updates and fundamentally cannot >>>change to streaming updates to architectural constraints so I don't want >>>to be stuck with a crippled non-streaming API >>> >>>Rob >>> >>> >>>On 2/5/13 3:09 PM, "Andy Seaborne" <[email protected]> wrote: >>> >>>>> I have unified the two update paths into a single path. I also >>>>> removed the ability to pass in an UpdateRequest into the >>>>> UpdateEngineFactory. In fact, I've eliminated all the places you >>>>> could pass one in. Since with the streaming capability, we won't be >>>>> able to have one. This required one change to the public API, >>>>> GraphStore.startRequest() and .finishRequest() no longer take an >>>>> UpdateRequest as an argument. This shouldn't be too much burden for >>>>> end users and implementors to adapt to. Also there is no >>>>> UpdateRequest available via the execution Context object (as it won't >>>>> be know ahead of time). >>>> >>>>Great! >>>> >>>>We'll need some documentation to explain the migration, hopefully more >>>>for the pre-release cycle than the release as that's when the extenders >>>>should be aware. >>>> >>>>I have fixed up the tests to work by removing the initial binding update >>>>tests. >>>> >>>>Currently, 3 tests, + support method, are commented out, with a note to >>>>say the commented code can be removed completely post 2.10. >>>> >>>>I have also cleaned up javadoc warnings (no such variable; class not >>>>imported). >>>> >>>>> Things left to do: >>>>> 1) Eliminate *or* deprecate the ability to pass in an initial >>>>> binding for update requests >>>> >>>>IMO Remove. >>>> >>>>If it the interface is change at all, remove, to avoid two changes, or >>>>more likely, deprecation for years. >>>> >>>>> 2) More javadocs around the UpdateEngine for implementors >>>> >>>>?? Or something on the website + link in javadoc -- your call >>>> >>>>> 3) Change the name/operation of UpdateVisitor >>>> >>>>Could you explain that please? >>>> >>>>> >>>>> -Stephen >>>>> >>>> >>> >> >
