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 >>>> >>> >> >
