From: Tony B. <ton...@ka...> - 2006-07-28 21:29:59
|
I've noticed that in some <ask> queries sort="..." doesn't seem to work. I've dug through the code a bit, and it seems that there is actually no code to handle $this->mSort inside the "conjunct is a print command" section - only in the "conjunct is a real condition" part. I'm assuming this means you can't sort by a field that you're not also restricting on. Is this (a)deliberate, (b) something that isn't implemented yet, or (c) something I'm doing wrong? Thanks, Tony |
From: Markus <ma...@ai...> - 2006-07-30 21:24:47
|
On Friday 28 July 2006 17:17, Tony Bowden wrote: > I've noticed that in some <ask> queries sort=3D"..." doesn't seem to work. > > I've dug through the code a bit, and it seems that there is actually no > code to handle $this->mSort inside the "conjunct is a print command" > section - only in the "conjunct is a real condition" part. > > I'm assuming this means you can't sort by a field that you're not > also restricting on. True. The docu should be more specific about this ... > > Is this (a)deliberate, (b) something that isn't implemented yet, or (c) > something I'm doing wrong? No, the thing is that print commands do not even require that a property ha= s=20 some value. If you want to sort by some property, you have to at least=20 restrict to thise things which have this property. This means you have to a= dd=20 a statement of the form [[relation::+]] or [[attribute:=3D+]] if you sort=20 by "relation" or "attribute". This is inevitable, since the print commands really are executed later. If = you=20 do a sort, you always get the first 50 (or whatever) results *after* sortin= g.=20 So the sort has to be done by the database before returning any results for= =20 which are then used for later print-commands. I think we could just add the +-statments to the query if sort is given and= =20 they are not present yet. But I am not sure whether this couldn't also be a= =20 source of other confusions. Cheers, Markus > > Thanks, > > Tony > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |
From: Tony B. <ton...@ka...> - 2006-07-31 08:12:24
|
On Sun, Jul 30, 2006 at 11:24:30PM +0200, Markus Kr?tzsch wrote: > No, the thing is that print commands do not even require that a property = has=20 > some value. If you want to sort by some property, you have to at least=20 > restrict to thise things which have this property.=20 I don't see this as being necessarily so. Perhaps in an overly strict intrepretation of NULLs or something, but most software is quite content to sort lists that include empty files. > This is inevitable, since the print commands really are executed later. I= f you=20 > do a sort, you always get the first 50 (or whatever) results *after* sort= ing.=20 > So the sort has to be done by the database before returning any results f= or=20 > which are then used for later print-commands. That makes sense. > I think we could just add the +-statments to the query if sort is given a= nd=20 > they are not present yet. But I am not sure whether this couldn't also be= a=20 > source of other confusions. It would if suddenly results started vanishing. Thanks, Tony |