On 06/06/12 19:39, Stephen Allen wrote:
On Wed, Jun 6, 2012 at 11:01 AM, Stephen Allen<[email protected]> wrote:
Hi Andy,
I was curious about a statement you made on the user list yesterday:
On Tue, Jun 5, 2012 at 2:43 PM, Andy Seaborne<[email protected]> wrote:
Updates don't log. Form submitted updates are buffered - the entire string
is available to be printed but ones sent as "application/sparql-update" are
stream read (e.g. a large INSERT DATA { .... })
I was looking at the parsing code, and it's true that
"application/x-www-form-urlencoded" updates are buffered into a String
early in the process, although it appears to me that for
"application/sparql-update", the ARQParser and SPARQLParser11 also
have to buffer all the update data in UpdateRequest objects (which for
the DATA methods are an in-memory list of Quads).
I have been thinking about how to make this process streaming but I
didn't know whether it made sense to try to modify the JavaCC parsers
to be streaming or try to build a hybrid parser for just SPARQL
Update. This hybrid would handle INSERT DATA and DELETE DATA in a
streaming manner, and delegate regular updates to the existing parser.
Do you have any thoughts or advice?
-Stephen
Another much simpler (although perhaps less satisfying) option would
be to replace the ArrayList in QuadAcc with a DataBag.
Partially - aren't we going to want to not allow other SPARQL operations
that aren't wanted when streaming? That's where I got to about a special
store language.
A SPARQL/Update can be several operations in a request. It's not just
what can be done but what needs to be made not possible.
Is there an order preserving DataBag impl? This is also used to
serialize updates as well.
Feels like both small/general/nice-errors, and
large/stream/less-nice-errors are pulling in different directions a little.
Andy
-Stephen
