Re: [Exist-open] weird behaviour between two XQueries that should do the same

[Pierrick B. <pie...@fr...>]

Hi,

Raul Davidovich a écrit :

>>> Could you provide the relevant par of the logs please ?
> I'll run them again today and send you the whole logs.

Thanks.

>>> Avoid constructing nodes (i.e. documents or elements) so early
> 
> I didn't find a way two execute two succesive for loops

Not sure XQuery knows what "successive loops" are :-) See below.

> if they're not
> inside a return clause or inside a document constructor. I might have
> something wrong here all the same...

Yes indeed.

More hints :

As I've previously said, try to contruct your elements as late as 
possible and avoid as much as possible constructing "temporary" nodes 
just to process them later in a way that you will find more 
convenient... but not the XQuery processor

To be more clear : constructing temporary fragments when you can deduct 
their structure from previous XQuery expresssions that don't use 
conditional expressions is a performance gap (although this could 
probably be optimized).

Notice that there is a difference between constructing and computing 
nodes ;-) Computing nodes infers that can't deduct your structure in 
advance (unless your query is really badly designed)

See the specs (as always) to get the defference between "computing" and 
"constructing" nodes.

>>> So, what you need is collection("/db/results/")/pricing right ?
> No..  

I'm afraid yes.

> <pricing> contains several result nodes,

All those nodes, unless I'm wrong, can easily be retrieved from the 
<pricing> elements in a determinist way. That makes <pricing> elements 
the root of your processing and an excellent factorization point IMHO...

>>> Create an outer loop that is able to pass 'mtm'....
> 
> It was the first thing I did, something like
> for $pricing in collection('/db/results/')/pricing
> return(
>      for $result in $pricing/results/result[@type='value' and @name='mtm']
>      return(
>          [[construct CSV line here]]
>      )
> 
> ... OTHER RESULT TYPES HERE
> )
> 
> but this took like 10 minutes to run,

That's not what I was saying. The only varying condition is @name=XXX. 
You'd better provide this XXX value from an iteration over a sequence of 
ad hoc xs:string's, i.e. an outer loop.

 > probably because of the same issue
> querying again and again the DB whereas the result should already be there

You can blame the DB if you provide arguments. I'd blame the design of 
the query first :-)

>>> you can even avoid this outer loop if you use "="

> I really don't get what you mean here :)

Everything is in the specs. Uderstanding how the "=" operator works 
really brings performance with XPath 2.0 and XQuery, not counting the 
fact that it makes query designing easier IMHO.

[yet another snip]

Cheers,

p.b.