Desarrollando aplicaciones J2EE sobre Alfresco III – campos tipo datetime

Además de las particularidades
sorteadas durante el desarrollo bajo Alfresco Community 3.4d,
un curioso problema con el que nos encontramos fue el uso del tipo
CMIS ‘d:datetime’.

Por defecto, el analizador de
tipo ‘datetime’ para Lucene de Alfresco tiene una implementación en
donde sólo se contempla el ‘date’, dejando a un lado el ‘time’. Como
consecuencia de esto, las búsquedas ‘ORDER BY cmis:creationDate’ no
conseguían resultados reales.

En la wiki
nos recomiendan configurar un analizador tipo Datetime

				#d_dictionary.datatype.d_datetime.analyzer=org.alfresco.repo.search.impl.lucene.analysis.DateAnalyser
d_dictionary.datatype.d_datetime.analyzer=org.alfresco.repo.search.impl.lucene.analysis.DateTimeAnalyser

Tras reconstruir
los índices todo funciona como debería. Lamentablemente, tener este
tipo de analizador nos modificó el comportamiento de las búsquedas por
fecha, no permitiendo encontrar objetos mediante el uso de predicados
CMIS-SQL tipo:

				SELECT * FROM eu:registro WHERE cmis:creationDate > '2011-01-10T09:09:55.965Z'

SELECT * FROM eu:registro WHERE cmis:creationDate > '2011-01-10T09:09:55.965Z' 
AND cmis:creationDate < '2011-01-12T09:09:55.965Z'

SELECT * FROM eu:registro WHERE cmis:creationDate>TIMESTAMP'2010-09-23T16:56:49.925+02:00' 

Tras probar varias sugerencias
leídas en la comunidad Alfresco [1]
[2]
[3]
y no conseguir solución decidimos cambiar de estrategia.

Decidimos abandonar el uso del tipo
‘d:datetime’ a favor de ‘d:long’ para almacenar las fecha como TimeMiliseconds
desde la fecha base de un calendario J2EE , denominado época (1
January 1970 00:00:00 GMT)

				<property name="eu:FechaInicioTimeMiliSeconds">
    <title>Fecha de inicio miliseconds</title>
    <type>d:long</type>
</property>

				metadatos.put(
  METADATA_FECHA_REGISTRO_MILISECONDS,
  Formatters.convertTimeToMiliseconds(io.getFechaRegistro())
);

Y ya lo tendríamos todo casi solucionado, si no fuera porque
en la implementación CMIS de Alfresco el tipo d:long de CMIS no se
interpretaba como tal, si no como un entero tipo d:integer que al
intentar recibir un ‘timemiliseconds’ nos generaba la excepción.

				Caused by: java.lang.NumberFormatException: For input string: "1320361200000"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:461)

Con un cambio de
‘d:long’ a ‘d:string’ todo solucionado!