Búsquedas case insensitive y Filters

[spilby]

Buenas,

tengo un problema que hace tiempo que no logro resolver, y compienza a ser ya vital solucionarlo.

Utilizo Alfresco 4.2.5.1. Necesito hacer búsquedas de metadatos que sean Case Insensitive, para encontrar cadenas ya sea en mayúsculas o en minúsculas.

Las búsquedas las realizo mediante ALFRESCO-FTS. Como ejemplo, utilizo el navegador de nodos del Share para probar. Son búsquedas de este estilo:

TYPE:"loquesea" AND =@exp\:exp_name:"Test 2016"

El problema es que no me busca indistintamente de las mayúsculas/minúsculas. Si tengo un "TEST 2016" y busco un "test 2016" no me lo encontrará, y necesito que me lo encuentre.

Si elimino el "=" que precede al campo a buscar en la query sí que hace la búsqueda insensitive, pero necesito de ese "=" ya que quiero buscar la cadena exacta, no parte de la cadena.

En mi modelo ese campo está definido así:

<property name="exp:exp_name" editVisible="true" createVisible="true" editable="true" inheritable="false" calculable="true">
   <title>Number exp</title>
   <type>d:text</type>
   <mandatory>true</mandatory>
   <index enabled="true">
       <atomic>false</atomic>
       <stored>false</stored> 
       <tokenised>both</tokenised>
   </index>
</property>   
‍‍‍‍‍‍‍‍‍‍‍‍

He hecho una prueba y cambiado el tokenised a false, para evitar tener que poner el "=" en la query, pero si lo pongo a false vuelve a ser case sensitive. Parece que lo que lo convierte en insensitive es el tokenised a both (o true).

Leí en un foro que inviertiendo el orden de los filtros LowerCaseFilterFactory y WordDelimiterFilterFactory en el schema.xml del solr lo conseguiría, pero lo he hecho y no funciona.

<schema name="alfresco" version="1.0">
   <types>
      <fieldType name="alfrescoDataType" class="org.alfresco.solr.AlfrescoDataType">
         <analyzer>
            <tokenizer class="org.apache.solr.analysis.WhitespaceTokenizerFactory" />
            <filter class="org.apache.solr.analysis.LowerCaseFilterFactory" />
            <filter class="org.apache.solr.analysis.WordDelimiterFilterFactory" 
                    generateWordParts="1"
                    generateNumberParts="1"
                    catenateWords="1"
                    catenateNumbers="1"
                    catenateAll="1"
                    splitOnCaseChange="1"
                    splitOnNumerics="1"
                    preserveOriginal="1"
                    stemEnglishPossessive="1"/>
         </analyzer>
      </fieldType>
   </types>
   <fields>
      <field name="ID" type="alfrescoDataType" indexed="true" omitNorms="true" stored="true" multiValued="true"></field>
      <dynamicField name="*" type="alfrescoDataType" indexed="true" omitNorms="true" stored="true" multiValued="true"></dynamicField>
   </fields>
   <uniqueKey>ID</uniqueKey>
   <defaultSearchField>ID</defaultSearchField>
</schema
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Además, la búsqueda puede ser tanto transaccional (directo a la BD) como por SOLR, por lo que entiendo que incluso resolviendo este problema en el fichero del solr seguiría teniéndolo cuando sea transaccional y no use SOLR.

He visto también que el dataTypeAnalyzer_es.properties utiliza SpanishSnowballAnalyser

Estoy seguro que de algún modo se puede configurar para que las búsquedas sean siempre case insensitive.

¿Qué puedo hacer para configurarlo?

Merci!

[angelborroy]

Bajo mi punto de vista, no hay solución de acuerdo a tus especificaciones.

Lo que yo haría: utilizar el LIKE (o el CONTAINS de las CMIS queries) y filtrar los resultados después en tu capa de integración. No es lo más elegante, pero creo que es lo único viable.

[spilby]

Hola Ángel, estás en lo cierto, no hay forma. He preguntado, leído, probado, incluso escribí al soporte oficial, y parece que es imposible.

Necesito usar el "=" ya que es la única forma que la query vaya a BD en lugar de a SOLR. (Se crean muchos ficheros casi simultáneamente y necesito las búsquedas inmediatas para comprobar si ya existen, sin esperar a que solr reindexe aunque tarde solo 2 segundos). Para que la consulta vaya a BD han de ser siempre exactas, con el "=" delante, o iría al SOLR. Y al añadir el "=" la consulta se vuelve case sensitive. No hay más.

En soporte me dijeron que la unica opción es customizarlo para que fuera insensitive (no sé customizar el qué, imagino que las clases de Alfresco que llaman a BD), pero que explicar cómo hacer eso tiene un coste de soporte. (Sinceramente, no sé para qué les pregunto, o me dan respuestas equivocadas, que ya me ha pasado muchas veces, o me dicen que hemos de pagar, menos mal que existe este foro o no sé lo que haría).

Soluciones que se me ocurren también… Al final Alfresco tira de un Oracle. Se podría configurar la propia BD para que según los campos que necesitemos sean Case Insensitive. Me han comentado que es posible hacer eso.

Otra opción: las propiedades a buscar que necesite que sean Insensitive, pasarlas todas a mayúsculas, haciendo un UpperCase cada vez. Las nuevas y las existentes. Y que las búsquedas sean siempre así. No respetamos lo que ha introducido el usuario, pero bueno, si no hay más remedio…

[angelborroy]

Te escribo mis ideas para que tengas alguna ayuda adicional, pero no parece que vaya a ser algo sencillo.

Supongo que pueden personalizarse las búsquedas FTS sobreescribiendo alguna(s) clase(s) de Alfresco, pero requiere un estudio detallado de cómo funciona la capa de DAO. Y habría que realizar una programación poco intrusiva para no afectar a ninguna otra funcionalidad.

En cuanto a configurar Oracle, supongo que la solución pasaría por alterar los índices de metadatos para que fuesen "case insensitive". Quizá sea lo menos agresivo para el sistema, aunque tampoco sé si esto tendrá efectos laterales.

Finalmente, cambiar el modo en que el usuario introduce las propiedades parece una solución un poco "retro" (sin ofender), pero podrías implementarla "por detrás": duplicas los campos en los que quieras buscar (p. e. exp_name_hidden) y los actualizas automáticamente cuando se introduzca el campo original. Al menos así podrás respetar la información para el usuario y te permitirá hacer tus consultas "en cocina".

Suerte!

[spilby]

Gracias por tus opiniones, Ángel, siempre son bien recibidas. Ojalá logremos la opción del Oracle, de ser así, os cuento por aquí qué tal, por si alguien más necesita lo mismo y así conoce nuestra experiencia.

Desde luego la tercera vía sería ya la desesperada, porque no me gusta nada de nada, pero sí es cierto que de no quedar otra podríamos hacer lo que comentas y tener ambos campos, el que mostramos y el de búsqueda, es una buena idea en caso de usar esa vía.

Os cuento en un tiempo qué hemos hecho y qué tal ha funcionado! Gracias de nuevo!