[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