You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
mdutoo
changed the title
Model Governance - frozenMixins
Issue tu be reused
Aug 31, 2015
mdutoo
changed the title
Issue tu be reused
Issue to be reused 253
Aug 31, 2015
mdutoo
changed the title
Issue to be reused 253
Further geo search jurisdiction : also on zipcode, parent geo area name...
Sep 1, 2015
mdutoo
changed the title
Further geo search jurisdiction : also on zipcode, parent geo area name...
Search geo jurisdiction on more fields : zipcode, parent geo area name...
Sep 1, 2015
…:name data; this removes the search by zip code, but avoids performance issues when searching by (not filtering by!) country -in odisp ALL cities and regions contain also the country : 'ville (zip) - country'.
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).
The text was updated successfully, but these errors were encountered: