Search is now only done on (cached, tokenized) geo:name.
Later, we could also allow search on:
zipcode (or other geo area field, which ones ?), by adding it to tokens, by using instead of tokenize(name) tokenize(dcResource) which applies tokenize(name) on a collection of conf'd fields
names of parent geo areas, by unencoding & splitting them from their URIs gotten from dcResource.get("oanc:ancestors")
other fields of parent geo areas, by getting them from the cache BUT this requires a getCachedOrUpdateCacheIfOlderThan(cacheRebuildStartTime) lazy cache access & filling approach (or a two-pass cache building algo, or getting them from Datacore but this is way too costly).
Don't do that before agreeing on the future of the current cache archi #236
Note that before, search was done on odisp:name, which allowed search on zipcode. But this has been changed because when users entered a country (ex. "france") as search input, it came with a heavy performance cost since ALL french geo areas (which all contain "France" in their display name) had to be scanned and sorted (in order to put the actual France geo area on top, otherwise it could never be found).
Be careful, the workflow of selection of zipcode then city or conversely isn't simple either from a functional point of view or from a technical one (jsx select2).
Search is now only done on (cached, tokenized) geo:name.
Later, we could also allow search on:
Don't do that before agreeing on the future of the current cache archi #236
Note that before, search was done on odisp:name, which allowed search on zipcode. But this has been changed because when users entered a country (ex. "france") as search input, it came with a heavy performance cost since ALL french geo areas (which all contain "France" in their display name) had to be scanned and sorted (in order to put the actual France geo area on top, otherwise it could never be found).