- From: Bas de Bakker <bas@x-hive.com>
- Date: Tue, 19 Nov 2002 09:12:49 -0500 (EST)
- To: "Jonathan Robie" <jonathan.robie@datadirect-technologies.com>, <public-qt-comments@w3.org>
> Yes, this is a good way of dealing with the way most > implementations work, > but it does amount to writing your queries in a particular > way because you > know that sort by is, in the general case, hard to optimize > when element > constructors intervene between input and output. True. But anytime I wrote SQL queries for real applications I also had to be very much aware of the query plan that would result. The declarative nature of query languages is only real when performance is not an issue, which is never the case. > True - and we discussed whether to keep sort by in addition > to the order by > clause. Many people felt that two different ways to do > sorting was too much > in a 1.0 release. I agree completely. > Your solution works nicely for this one example, but I'm not > sure if it > generalizes. Suppose I want to group by the author's last > name, then first > name. How would I do this? group $books in ... by value $lastname = ./author/lastname return <lastname name="{$lastname}">{ group $somebooks in $books by value $firstname = ./author/firstname return <firstname name="{$firstname}">{ for $b in $somebooks return <title>{$b/name}</title> }</firstname> }</lastname> or if you don't need the name hierarchy group $books in ... by value $firstname := ./author/firstname by value $lastname := ./author/lastname {-- could add where/order by clauses on $firstname/$lastname --} return <name firstname="{$firstname}" lastname="{$lastname}">{ for $b in $books return <title>{$b/name}</title> }</name> Regards, Bas de Bakker X-Hive Corporation
Received on Tuesday, 19 November 2002 12:42:36 UTC