From: Pierrick B. <pie...@fr...> - 2007-08-16 14:59:02
|
Hi, Raul Davidovich a écrit : First, I'm quite picky on Netiquette rules (defined by some other specs known as RFC 1855). Sending a 62 kb document to every subscriber of this mailing-list is not very gentle. Sorry. >>> 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. > > What I mean is that the line: > > string-join((bla,bla,bla),",") > > is different for each combination of @name=xxx and @type=xxx Right, so... why not use a conditional expression (namely an if ... then ... else statement at that level, i.e. as late as possible ? > so for me the processing of the result nodes > /pricing/results/result[@name='mtm' and @type='value'] is totally > different than the processing of the result nodes > /pricing/results/result[@name='default' and @type='sensitivity']... > apples and oranges, even if they look the same. (this might not be the > optimal solution for returning the results, I agree) It isn't IMHO. > I have no control about the structure of this XML as it's produced by an > external application, so chainging ti to something more meaningful is not > an option. It isn't for most of us. > I really fail to see how to achieve this with something like (not in > xquery syntax): > > array params = {[mtm, value], [default,value], > [expected_loss,sensitivity]....} > > > for pricing in collection('/db/results')/pricing > for param in params > for result in pricing/results/result[@name=param[0] and @type=param[1]] > return > string-join(......) > > it's not like I could factor out a function and do the same thing once and > again, because that "string-join" line is strictly different each time. That's more or less how you should do though. And if your string-join() needs more control, use a conditional expression or define a function whose parameters will be under *your* control. Working like this is the XQuery way and what brings more performance because we try to optimize these kind of constructs... >>> As I've previously said, try to contruct your elements as late as >>> possible and avoid as much as possible constructing "temporary" nodes > > I would love to do this, specially that I don't need the XML... only the > text CSV lines (as you may already have guessed) > > but since I've to do things like > > for blablabla return(something) > > for blablabla2 return(something else) > > ..more for blablablas > > <<return the result of each for in a single result set or single text>> > > I didn't find any other way than to execute them inside a document{} > constructor> and then iterate through this document's nodes returning > their content. As such, there is little chance to have an efficient factorization. However, consider this : for $blabla in /common/path/to/all/processed/nodes return if ($bla) then X else if($blabla2) then Y else Zblas > As for the logs (attached), I got the latest version from the SVN trunk, > and still have the same issue when defining a variable, and a Unsupported > execution mode: '-1' error when doing it inline in the string-join() Bad news. Such an execution mode should be impossible. It might have been fixed since the RC though... Well, I'll have a look when I have time. >>> 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. > > I still really, really, really don't get your point about the "=" operator > and about how it can avoid the loop.. "=" operates on *sequences*, i.e. multiple items (OK, a single item is also a sequence but let's keep it simple). Rather than iterating over (or processing) 1 item N times, if is often more clever to iterate (or process) one time over a sequence of N items. A lot of people, including myself, often use "=" where they shoud use "eq" ; that sometimes demonstate a bad XQuery design :-) Definitely use "=" as often as you can, but don't complain about poor performance if "=" is treated as "eq". > I believe it's the operator I'm using... Could you use "eq" instead ? If yes then... your design can be improved. > The only thing where I find there might be an issue is that when doing > > $something := $bla/somechild/somesubchild > string-join(('hello: ', $something),',') > (querying the DB thousands of times, complaining it cannot find an index) > > the behaviour is not the same as when doing > > string-join(('hello: ', $bla/somechild/somesubchild),',') > (querying the DB once) > > Whereas, unless I'm terribly wrong, they should be the same. Can't tell. Your statements are not valid XQuery and none of them uses an index. > I've been working with Java and SQL for the last 7 years, so I know my > skills there, and been working with XQuery for the last 7 days :-) so it's > very likely that my XQueries are far away from being great. Let's improve them then :-) Your query, given what you have said until now, shouldn't take more than a few seconds. You'd really want to consider generating that CSV line as late as possible, i.e. when all your previous statements have proved to be efficient... and correct [netiquette snip of the tail quotation] Cheers, p.b. |