[Mulgara-dev] Emailing: protocolServlet POST answercleanup.patch

Paul Gearon gearon at ieee.org
Wed Jan 20 01:20:07 UTC 2010


On Tue, Jan 19, 2010 at 7:58 PM, David Smith <DMS at viewpointusa.com> wrote:
> Got, will try it out.
> I still think that the protocolServlet handleUpdateQuery() needs some
> attention.
> It currently only renders the last real answer encountered.
> Any others need to be closed properly (again even with subqueries)

Yes, you're right.

I actually did it as a companion to the SPARQL endpoint, so I was
thinking in terms of SPARQL the whole time. SPARQL doesn't have
sub-answers, and it doesn't have multiple queries in a single request,
so I didn't give adequate thought to either of those situations in
TQL.

Incidentally, SPARQL Update *does* accept multiple operations in a
single request. So I need to make sure this part of the servlet is
working by the time I get SPARQL Update implemented!

> OR implement the render multiple answers into one return result  :)

I absolutely think I need to do it this way. Unfortunately, I'll need
to change the interfaces to the output streaming classes to handle
multiple Answers, but I'm sure that will be fine.

> I looked at that briefly, wouldn't be too bad,
> Separate the docheader into pieces, add idea of list of answers --
> change the single answer funcs to convert to a 1 element list,
> and then get emit/generate to understand the list,

Yup, exactly the approach I was considering. I've been spending a lot
of time in Scala recently (to run the SPARQL test suite against
Mulgara), so thinking in terms of lists is coming quite naturally at
the moment.  :-)

> but should be implemented on all streamed answer classes and I'm not
> sure I know what each should do.

Don't worry... I do.  :-) It's a nice, easy looking task. Just the
kind of thing I can do to avoid work (but it will be tomorrow, rather
than tonight, sorry. I'm tired).

> Might be enough to just handle the last Answer in the classes that don't
> want/understand more.

Only TQL needs this special treatment, though the general interfaces
will need to accept lists (the SPARQL versions will need to check that
the list is a singleton). TQL is the only REST interface that can
return more than one query result, and is the only REST interface that
can return sub-answers. SPARQL answers are being covered pretty well.

> Thanks for your help.
>
> I'll let you know how it works out.

I'll see you in the morning.

Regards,
Paul Gearon



More information about the Mulgara-dev mailing list