Fulltext search on more types : on ex. cities, countries, up to organizations on display & alt name...

Several solutions of increasing cost and usefullness:

1 by extending geo cache:

20151009 DONE IN #277 copy mixin name or model type (@type) to allow to restrict search on it ex. cities (simple, almost done)
make its "geoarea" conf a generic list of such models, to allow to cache several different storage (or stored) models, ex. also NACE.
allow to search in several Datacore fields at once (ex. org display & alt name) by filling search tokens from all of them (requires more complex conf & batch replication of which several fields of several Models)
up to having several mongo collections, one per separate index, in order to allow to have separate lookup in ex. org display & alt name (even more complex)

BUT

this is still not well suited to changeable / not cold data such as orgs, because it will quickly be unable to return newly added data and return obsolete (newly deleted) ones ; unless more work is done to handle in realtime ex. new orgs (not that hard on portal side, in local event fashion) and deleted ones (far harder, either by suppl daily checks and still handling errors, or by remote event API & subscription yet to be developed).
apps other than the portal will never be able to use it, and will have to redo all of it according to their needs on their own. A workaround is for them to use dropdowns to select consecutively country, NUTS2/3, then city ; this works well for Turkey, maybe for other EU countries, but most probably not for France (too much levels AND cities).

2 or even reuse it on Datacore side:

share tokenizer in lib and reuse it to auto filll a "osearch:tokens" (DCEvent-) computed field in Datacore Resources that enable it and in Datacore Java client
and up to allowing to search in different storage models i.e. instantiating one cache for each storage model. To do it: make generic DatacoreBusinessFulltextCache (business object) and concretize GeographicalAreaFulltextCache extends DatacoreBusinessFulltextCache created in its own @Configuration classes (one per storage model) see http://stackoverflow.com/questions/11845871/spring-value-annotation-inheritance-and-common-fields-but-different-values

BUT

it won't scale up => 2 Cache as a Service
- to answering massive needs such as portal's unlogged home page first main feature (autocompletion on geoarea)
- to handling outlier use cases: if a field is required to be searched fulltext only by a single app, it is overblown to make it a fulltext field, and this app should have its own fulltext-able cache (and possibly use the Datacore for that: maintain its own copy model with a single difference at storage level i.e. said field as fulltext => an idea for how to do Cache as a Service on Datacore side)
THIS ENDS UP REDOING THE WHEEL i.e. reimplementing our own fulltext search engine ! So let's not do that unless it stays very simple. => 3 reimplement on top of ex. Elastic Search

2 so make it available as an API-subscribable and configurable on demand service, as much as possible, typically using OCCIware

3 and go towards a clean archi:

not redo the wheel: reimplement the geo cache (out of the portal) on top of a best-ot-breed open search engine Elastic Search (TODO Q is being remote OK ?) (or even business-level cache à la Memcached ???) ; and develop said features, towards a universal Datacore fulltext search engine
let its configuration be Datacore Models and Mapping / Synchronization (Transformations) once it'll be developed, rather than adhoc. This way, it becomes a Datacore implementation over ex. Solr.

ozwillo / ozwillo-portal