Formato de almacenamiento de metadatos incrustado de Tridion 2009 en el corredor

Question

Soy bastante nuevo en Tridion y tengo que implementar una funcionalidad que permita a un editor de contenido crear un componente y asignarle varios intervalos de fechas (fechas disponibles). Estos deberán ser consultados por el agente para proporcionar una funcionalidad de búsqueda.

Originalmente, esto solo requería una única fecha de inicio y finalización, por lo que se implementaron como campos de metadatos individuales.

Propongo utilizar un esquema incrustado dentro del campo de metadatos 'fechas disponibles' del esquema para permitir que se asignen múltiples fechas de inicio y finalización.

Sin embargo, como el campo ahora permite valores múltiples, los datos se almacenan en el intermediario como valores separados por comas en la columna 'KEY_STRING_VALUE' en lugar de como un valor de fecha en la columna 'KEY_DATE_VALUE' como solo permitía un único valor de inicio y final.

por ejemplo.
KEY_NAME | KEY_STRING_VALUE
end_date | 2012-04-30T13: 41: 00, 2012-06-30T13: 41: 00
fecha de inicio | 2012-04-21T13: 41: 00, 2012-06-01T13: 41: 00

Esto ahora está causando problemas con las consultas de mi broker ya que no puedo usar la lógica de consulta simple para recuperar los elementos que necesito para la búsqueda basado en las fechas.

Antes de comenzar a escribir la lógica C# para analizar estas fechas separadas por comas y buscarlas, me preguntaba si alguien había tenido requisitos/experiencias similares en el pasado y lo había implementado de una manera diferente para reducir la cantidad de requiere el análisis de código y para usar la consulta del agente para completar la búsqueda.

estoy desarrollando en este Tridion 2009, pero utilizando el 5,3 Broker (por razones de compatibilidad) lo que la consulta actualmente parece que esto (por las fechas individuales de inicio/final):

query.SetCustomMetaQuery((KEY_NAME='end_date' AND KEY_DATE_VALUE>'" + startDateStr + "') AND (ITEM_ID IN(SELECT ITEM_ID FROM CUSTOM_META WHERE KEY_NAME='start_date' AND KEY_DATE_VALUE<'" + endDateStr + "')))"; 

cualquier ayuda se apreciado enormemente.

Answer 1

Este es un escenario complejo, ya que tendrá que ir a lo largo de todo el PRD y analizar esas cadenas para determinar si coincida con los criterios de búsqueda

hay una manera que podría convertir ese metadatos (separadas por comas) en una sola valores en el intermediario, pero el nombre de los campos debe ser diferente Rango1, Rango2, ...., RangoN Puede hacer eso con una extensión desplegadora donde cambie la Estructura XML del paquete y convierta cada una de esas cadenas en diferentes valores (1,2, .., n). Esta extensión puede llevar algo de tiempo si no está familiarizado con las extensiones de implementador y no resuelve el 100% de su situación.

El problema de esto es que usted todavía tiene que aplicar varias condiciones para recuperar esos valores y siempre hay un límite de lo que tiene que establecer (versus el usuario que puede agregar valores de mayo como quiere)

de la muestra:

query.SetCustomMetaQuery((KEY_NAME='end_date1' 
query.SetCustomMetaQuery((KEY_NAME='end_date2' 
query.SetCustomMetaQuery((KEY_NAME='end_date3' 
query.SetCustomMetaQuery((KEY_NAME='end_date4' 

Probablemente la forma más rápida y más sencilla de conseguirlo es en lugar de utilizar un campo de valor múltiple, utilizan diferentes campos. Entiendo que no es el escenario más genérico y existen implicaciones de los requisitos comerciales, pero puede simplificar el desarrollo.

Mis comentarios anteriores están en el contexto de usar solo la API de Broker, pero puede aprovechar un motor de búsqueda si es parte de su arquitectura. Puede indexar la base de datos del intermediario y dar masajes a los datos. Utilizando la API del motor de búsqueda puede extraer los identificadores de los componentes/plantillas de componentes y usar la API del intermediario para recuperar la información adecuada

Answer 2

Solo quería volver y dar algunos detalles sobre cómo finalmente me acerqué a esto si alguien más se enfrentara el mismo escenario

Propuse el número de campos establecido para el cliente (como lo sugirió Miguel) pero el cliente no estaba satisfecho con ese nivel de restricción.

Por lo tanto, terminé implementando el esquema incrustado que contiene las fechas de inicio y finalización que dieron la mayor flexibilidad. Sin embargo, las limitaciones en la API de Broker significaron que tenía que acceder directamente a la base de datos de Broker, lo cual no es ideal, pero el cliente ha aceptado el enfoque para obtener la funcionalidad requerida. Obviamente, esto debería revisarse en caso de que se realicen actualizaciones en el futuro.

Todo el procesamiento de las fechas y los períodos disponibles se realizaron en C# lo que significa que el rendimiento de la solución es bastante bueno.

Una cosa que descubrí que causó algunos problemas fue que si tiene múltiples valores para el campo utilizando el esquema incrustado (es decir, en este caso, múltiples fechas de inicio y finalización), los metadatos se almacenan en el KEY_STRING_VALUE columna en la tabla CUSTOM_META. Sin embargo, si solo tiene un valor único en el campo (es decir, una fecha de inicio y finalización), estas se almacenan como fechas en la columnaKEY_DATE_VALUE de la misma manera que si acabara de usar campos individuales en lugar de un esquema incrustable . Parece un enfoque sensato para Tridion, pero sirve para hacerlo un poco más complicado cuando se escriben las consultas y el código de análisis.