Feature Proposal: Make Search order param consistent with query

Motivation

At the moment, the set of elements you can order a search on is legacy $formfield() and a number of special aliases createdate. It is however not possible to Query based on createdate, or sort by queryable topic elements.

Unifying the accessor code in orderby to use the same code as the query implementation QueryAlgo::getField() would give us a 1:1 match between what can be queried and what can be sorted.

Description and Documentation

I'd like to extend this to use query aliases, or even (if possible) the full set of scalar elements returnable by QUERY (ie, getField)

At the same time, the few order elements we can't easily query on, such as createdate will be added as aliases to getField(), so that we can consistently select and order on the same fields - this is essential for a fully qualified SEARCH.

Examples

this enables queries to be written using a new alias to the first revision's info:

1. createusername - implemeted as META:CREATEINFO.author in a Query
2. createusername - implemeted as META:CREATEINFO.date

These were chosen to parallel the META:TOPICINFO query syntax.

META:CREATEINFO will be identical to versions[-1].info (until that changes to versions[1].info when I reverse the list), but will provide an opportunity for search implementers to cache the info in a way to avoid JOINs or other expensive lookups (like using a direct cache rather than using rcs).

Impact

WhatDoesItAffect:

Implementation

-- Contributors: SvenDowideit - 25 Apr 2011

Discussion

Using the query syntax makes perfect sense to me, for example,

order="versions[-1].info.author"

to sort on the author field of the first version of any matched topic. Or

order="fields[name='sausage'].value"

which would be synonymous with formfield(sausage). However the addition of aliases to (essentially) overcome a shortcoming of the store/search engine reeks of hwsnbnism. Ultimately I hate the idea of the query language, the formatter language and the sorting language have three overlapping sets of aliases. YUCK! So if you must do createinfo in the ordering language, you must also do $createinfo in the formatter (and properly, createinfo and formfield as reserved words in the query language too)

-- CrawfordCurrie - 03 May 2011

oh damn, you've actually argued for the opposite of what you think you are, and worse, not what I was hoping

you see, we've always had order=createdate, and format=$createdate (and createauthor and a bunch of others not doccoed) - which suggests that rather than adding a =META:CREATEINFO to avoid adding aliases at all, I should add more aliases to the query language

cos whatever wonderfulness we add, we'll be keeping the old mess.

I'm commiting the =META:CREATEINFO version so I can get somewhere while we continue to contemplate our doom.

-- SvenDowideit - 04 May 2011

Rather than a whole bunch of new $tokens, why don't we just add $query() ? $query(createinfo.author) synonym for $createuser

Then maybe I could do this:

%SEARCH{
  "1" type="query"
  order="parent.name"
  format="   * $formfield(ScientificName) has these predators: $percntFORMAT{
    \"$query(META:SLPROPERTYVALUE[property='PreyOf'].value)\"
    type="topic"
    format=\"$dollarquery('$dollartopic'/ScientificName)\"
    separator=", "
  }$percnt."
}%

Whereas atm the format string looks more like

%SEARCH{
  "1" type="query"
  format="   * $formfield(ScientificName) has these predators: $percntFORMAT{
    \"$percntQUERY{\"'$topic'/META:SLPROPERTYVALUE[property='PreyOf'].value\"}$percnt\"
    type="topic"
    format=\"$dollarpercntQUERY{\\\"'$dollartopic'/ScientificName\\\"}$dollarpercnt\"
    separator=", "
  }$percnt."
}%

-- PaulHarvey - 04 May 2011

er, um, adding format tokens like $query and $include as DelayedEvaluationOperators is a different proposal

-- SvenDowideit - 12 May 2011

I think the META:CREATEINFO and "sort on any getField expression" deserve to be separate line items in the release notes. So I created Tasks.Item11022 for the sort part, existing CREATEINFO work remains in Tasks.Item10678.

-- PaulHarvey - 05 Aug 2011

It appears that this has been partially implemented. Tasks.Item10678 is closed. But developers are gone, changing to Parked.

-- Main.GeorgeClark - 19 Nov 2015 - 18:09