Re: Re: Re: Query causes a StackOverflowError

2014-03-18 Thread Chris Dollin 
On Tuesday, March 18, 2014 02:46:13 PM Rob Walpole wrote:
> On Tue, Mar 18, 2014 at 11:59 AM, Chris Dollin  Actually what we used in the end looked like:-
> 
>  elda:supportsNestedSelect
> "true"^^xsd:string .

Just `true` will do. (It's a built-in SPARQL term.)

> Fuseki then said it was using nested selects (in the 500 error) - but it
> didn't make any difference to the problem.

> > If the fix Rob made was to change from labelledDescribeViewer to
> > a simpler viewer like api:describerViewer then that's a confirmation
> > and I'll add an issue to the issues list.
> >
> >
> The thing is we do actually want the labels from all the viewed items as we
> use these elsewhere. 

Sure, I just wanted confirmation that your existing view needed 
Elda to run the label query, ie that my hypothesis about what was
exploding was sound. I'll add it to the issues list and address it
(not necessarily immediately -- there's the Expires: release to do
first and Non-Elda Things).

A heads-up: doing the revisions to cache usage for Expires: has
changed some APIs inside APIQuery. You may want to pull
the cache-control branch into a local repo and see if the merge
is horrible for you or not.

Chris

-- 
"You work with mad scientists and you're surprised at a talking /cat/?"
/Girl Genius/

Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)

Re: Re: Query causes a StackOverflowError

2014-03-18 Thread Rob Walpole 
On Tue, Mar 18, 2014 at 11:59 AM, Chris Dollin  wrote:

> On Monday, March 17, 2014 06:17:10 PM Adam Retter wrote:
>
> > We did try using the:
> >
> > "yourSPARQLEndpoint elda:supportsNestedSelects true."
> >
> > Although I think we found that the option was actually (non-plural):
> >
> > "yourSPARQLEndpoint elda:supportsNestedSelect true."
>
> Oops, sorry.
>

Actually what we used in the end looked like:-

 elda:supportsNestedSelect
"true"^^xsd:string .

Fuseki then said it was using nested selects (in the 500 error) - but it
didn't make any difference to the problem.


>
> If the fix Rob made was to change from labelledDescribeViewer to
> a simpler viewer like api:describerViewer then that's a confirmation
> and I'll add an issue to the issues list.
>
>
The thing is we do actually want the labels from all the viewed items as we
use these elsewhere. As the generated union query seemed to be the root of
the problem we switched to using our Elda construct extension so we could
have an endpoint like this:

spec:record-list a apivc:ListEndpoint
; apivc:uriTemplate "/record-list/{uuid}"
; apivc:variable [apivc:name "uuid"; apivc:type xsd:string]
; tna:construct """
CONSTRUCT { ?member rdfs:label ?label . }
  WHERE {
?recordList dcterms:identifier ?uuid ;
dri:recordListMember ?member .
?member rdfs:label ?label .
}
"""
.

The query takes a while to run (there are approx 10,000
dri:recordListMember entries) but we get a result back eventually with no
stack overflow problem.

Rob
-- 

Rob Walpole
Email robkwalp...@gmail.com
Tel. +44 (0)7969 869881
Skype: RobertWalpolehttp://www.linkedin.com/in/robwalpole

Re: Re: Query causes a StackOverflowError

2014-03-18 Thread Chris Dollin 
On Monday, March 17, 2014 06:17:10 PM Adam Retter wrote:
 
> We did try using the:
> 
> "yourSPARQLEndpoint elda:supportsNestedSelects true."
> 
> Although I think we found that the option was actually (non-plural):
> 
> "yourSPARQLEndpoint elda:supportsNestedSelect true."

Oops, sorry.

> However, whilst Elda reported that it did indeed support the
> NestedSelect, it continued to create that absolutely massive union for
> our query.
> 
> The good news is my colleague Rob was able to change Elda's config
> file so that it generated a much simpler query for us. So we have now
> moved past that one. If anyone wants more info on this, please say,
> and I will ask him to post some detail.

I think this is a problem with views that ask for labels on the viewed
items (ie based on the view called "all", referenced with 
"api:labelledDescribeViewer"). The code that requests the object
labels doesn't have a fallback if there are lotsandlots of selected
items. 

If the fix Rob made was to change from labelledDescribeViewer to
a simpler viewer like api:describerViewer then that's a confirmation
and I'll add an issue to the issues list. 

Chris

-- 
"A facility for quotation covers the absence of original thought."/Gaudy Night/

Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)