accessibility (2) ADF (1) archiver (3) cmu (1) contributor (13) cookie (1) DAM (3) date (3) download (3) dynamic list (4) ephox (5) fatwire (1) fck (1) filters (1) folders (4) headers (2) IBR (3) ImageAlchemy (3) java (4) javascript (2) layout/template (4) link (6) locale (2) multilingual (1) rendition (3) replicator (4) rules (1) schema (1) search (11) sites (1) sitestudio (24) ssp/sspu (5) SSUrlFieldName (2) stellent (4) timezone (1) urm (1) weblogic (1) workflow (2)

Tuesday, 13 December 2011

More on OracleTextSearch deficiencies

I was so focussed on exploring multiple sort criteria with OracleTextSearch that it was pointed out to me afterwards that even a single sort criteria fails. Shonky stuff!

The MultiSort component was "fixed" in late 2009 to identify optimised fields and ignore the rest. That means it provides sorting on 5 fields only - date, title, ID, security and type. Considering there are typically just a few security groups and content types it's hardly worth using. Installing URM gives one more field. Whoopdie doo.

I'm sticking with Database.Fulltext search. Sure it's slower to rebuild and doesn't have fancy drilldown features - but it works the way it is supposed to.


  1. Just realised a dead simple way to avoid the problems of OracleTextSearch but retain the indexing benefits. When using OracleTextSearch, put "SearchEngineName=Database" into your search requests. This reverts to a metadata-only search query with all your search and sorting options restored! Set up a global rule with this as a side-effect.

  2. I have to integrate Endeca Search with UCM, Do you have any IDEA?