You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@jena.apache.org by Bob Morris <mo...@gmail.com> on 2012/06/05 21:40:04 UTC

can fuseki be invoked so that arriving queries are logged?

I am using Fuseki from
jena-fuseki-0.2.2-incubating-20120509.202022-18-distribution.zip in
conjunction with SPARQLPuSH [1].  So far,  most of my difficulties
surround providing the right details of the queries when constructed
by the the PHP that implements SPARQLPusH.  My debugging life would be
much easier if I could get fuseki to reveal  the queries it receives
via http, both post and get, before logging its response.

Is there a way to force this?

Use case:

Right now my debugging tends to take the form of figuring out where in
the PHP app the query is constructed,  making that point log to the
apache server supporting the PHP, grabbing the query there and putting
it into the fuseki web query form, and hoping that the error  reported
corresponds reasonably to the one signalled by fuseki when started in
a Linux shell.  I'd rather see those hints coming out of Fuseki
before I dig into the calling code. Otherwise, I am hopping back and
forth between my own Apache server logs and the reports Fuseki makes
of its issues with my queries.

Ideally, I'd be able to optionally see the query url-decoded, since
the url-encoding library of most(?) application languages is rarely(?)
problematic.

Thanks
Bob Morris


[1] http://code.google.com/p/sparqlpush/

-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390

IT Staff
Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob@gmail.com
web: http://efg.cs.umb.edu/
web: http://etaxonomy.org/mw/FilteredPush
http://www.cs.umb.edu/~ram
===
The content of this communication is made entirely on my
own behalf and in no way should be deemed to express
official positions of The University of Massachusetts at Boston or
Harvard University.

Re: can fuseki be invoked so that arriving queries are logged?

Posted by Andy Seaborne <an...@apache.org>.

On 06/06/12 19:01, Stephen Allen 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<an...@apache.org>  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).

Yes and no.  The input stream is directly parsed to a syntax tree so the 
string (the body) of the POST is not available to be printed.  There is 
"just" the one copy.

It also means if there is a parse error, the request is not printed in 
normal set up.

This is a balance - HTTP is generally about validate-execute and also it 
is good to know the operation is valid before starting (not everything 
is transactional).

Maybe it should be less clever and do string-log-parse-execute.

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

There is a tension between operations of just INSERT/DELETE DATA and 
combined, complex multi-part operations.  The latter leans towards 
complex parsing of whole sequences of actions before any operation.

So I think a separate, streaming, bulk-focused parser for INSERT DATA 
and DELETE DATA would be the way to go (and update processor etc).

javacc sharing is not something I have ever managed to get working to 
separate the grammar from actions without distorting the entire thing to 
be dominated by that design goal.  I have tried to remove all code from 
the parser, and just use events and the parser is streaming, the super 
class code builds the state.  It could be redone to pass in a builder, 
not use the superclass.  SPARQL Update does include the whole of SPARQL 
Query pattern matching.

So it's a bit of a mess from the multi-use point-of-view but the spec is 
stable so copy is tolerable (if somewhat irritating from an aesthetic POV).

Actually, this looks like the tip of a general need for a non-SPARQL (or 
SPARQL+ if you prefer) remote interface to Fuseki.  See also the users@ 
question and transactions across several Fuseki operations.

So may there is a language lurking around here somewhere.  It would 
stream-execute. More fine grained than GSP, less than full SPARQL Update.

INSERT DATA, DELETE DATA
BEGIN/COMMIT/ABORT
CLEAR/DROP, LOAD
CREATE DATASET, DROP DATASET
UNMOUNT DATASET
MOUNT DATASET
BACKUP DATASET
...

	Andy

>
> -Stephen