Встроенный формат хранения метаданных Tridion 2009 у брокера

Question

Я довольно новичок в Tridion, и мне нужно реализовать функциональность, которая позволит редактору содержимого создавать компонент и назначать ему несколько диапазонов дат (доступных дат). Они должны быть запрошены у брокера для обеспечения функциональности поиска.

Первоначально это требовало только одной даты начала и окончания и поэтому реализованы как отдельные поля метаданных.

Я предлагаю использовать встроенную схему в поле метаданных «доступные даты» схемы, чтобы можно было назначить несколько дат начала и окончания.

Однако, поскольку поле теперь допускает несколько значений, данные хранятся в брокере как значения, разделенные запятыми, в столбце «KEY_STRING_VALUE», а не как значение даты в столбце «KEY_DATE_VALUE», как это было, когда оно было допускается только одно начальное и конечное значения.

например.
KEY_NAME | KEY_STRING_VALUE
end_date | 2012-04-30T13: 41: 00, 2012-06-30T13: 41: 00
start_date | 2012-04-21T13: 41: 00, 2012-06-01T13: 41: 00

Это вызывает проблемы с моим брокером, поскольку я больше не могу использовать простую логику запроса для извлечения элементов, которые мне нужны для поиска на основе дат.

Прежде чем я начну писать логику C# для анализа этих дат и поиска по запятой, основанных на этих данных, мне было интересно, были ли у кого-то аналогичные требования/опыт в прошлом и внедрили это другим способом, чтобы уменьшить количество необходимо выполнить синтаксический анализ кода и использовать запрос брокера для завершения поиска.

Я развиваю это на TRIDION 2009 года, но с использованием 5.3 Брокера (для устаревших причин), поэтому запрос в настоящее время выглядит следующим образом (для отдельных дат начала/конца):

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 + "')))"; 

Любой помощь очень оценили.

Answer 1

Это сложный сценарий, так как вам придется идти по всей ПСД и разобрать эти строки, чтобы определить, соответствуют критериям поиска

Существует способ, можно преобразовать эти метаданные (разделенные запятой) в одиночном значения в брокере, но имена полей должны быть разными. Диапазон1, Range2, ...., RangeN Вы можете сделать это с расширением развертывания, где вы меняете структуру XML пакета и конвертируете каждую из этих строк в разные значения (1,2, ..., n). Это расширение может занять некоторое время, если вы не знакомы с расширениями развертывания и не решаете 100% ваш сценарий.

Проблема в том, что вам все равно придется применить несколько условий для получения этих значений, и всегда есть предел, вы должны установить (в сравнении с пользователем, который может добавить столько значения, как хочет)

Пример:

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

Вероятно, самый быстрый и простой способ добиться того, чтобы вместо этого использовать поле в многозначное, используйте разные поля. Я понимаю, что это не самый общий сценарий, и есть последствия для бизнес-требований, но могут упростить разработку.

Мои предыдущие комментарии в контексте использования только API-интерфейса брокера, но вы можете воспользоваться поисковой системой, если это часть вашей архитектуры. Вы можете проиндексировать базу данных брокера и массировать данные. Используя API поисковой системы, вы можете извлечь идентификаторы шаблонов компонентов/компонентов и использовать API-интерфейс брокера, чтобы получить правильную информацию.

Answer 2

Просто хотел вернуться и дать некоторые сведения о том, тот же сценарий.

Я предложил заданное количество полей клиенту (как предложил Мигель), но клиент не был доволен этим уровнем ограничения.

Поэтому я завершил внедрение внедряемой схемы, содержащей даты начала и окончания, которые дали большую гибкость. Тем не менее, ограничения в API Broker означали, что мне приходилось напрямую обращаться к Брокерской БД - не идеально, но клиент согласился на такой подход, чтобы получить необходимую функциональность. Очевидно, что это нужно будет пересмотреть, если какие-либо обновления будут сделаны в будущем.

Вся обработка дат и доступных периодов была выполнена в C#, что означает, что производительность решения на самом деле очень хорошая.

Одна вещь, которую я обнаружил, вызвала некоторые проблемы, заключалась в том, что если у вас есть несколько значений для поля с использованием встроенной схемы (то есть в этом случае несколько дат начала и окончания), тогда метаданные хранятся в KEY_STRING_VALUE столбец в CUSTOM_META стол. Однако, если у вас есть только одно значение в поле (то есть одна дата начала и окончания), они сохраняются как даты в столбце KEY_DATE_VALUE так же, как если бы вы использовали только отдельные поля, а не встраиваемую схему , Кажется разумным подходом для Tridion, но это помогает сделать его несколько сложнее при написании запросов и кода синтаксического анализа!