Format przechowywania metadanych Tridion 2009 w brokerze

Jestem całkiem nowy w Tridion i muszę zaimplementować funkcjonalność, która pozwoli redaktorowi treści utworzyć komponent i przypisać do niego wiele zakresów dat (dostępnych dat). Należy je przesłać z brokera w celu zapewnienia funkcji wyszukiwania.Format przechowywania metadanych Tridion 2009 w brokerze

Początkowo wymagało to tylko jednej daty rozpoczęcia i zakończenia, a zatem zostały zaimplementowane jako indywidualne pola metadanych.

Proponuję użyć osadzonego schematu w polu metadanych "dostępne daty" schematu, aby umożliwić przypisanie wielu dat rozpoczęcia i zakończenia.

Jednakże, pole jest teraz umożliwiając wiele wartości danych są przechowywane w pośrednika w przecinek oddziela wartości w kolumnie „KEY_STRING_VALUE” raczej niż data w kolumnie „KEY_DATE_VALUE”, jak to było gdy było dozwolone są tylko pojedyncze wartości początkowe i końcowe.

np.
KEY_NAME | KEY_STRING_VALUE
data_końcowa | 2012-04-30T13: 41: 00, 2012-06-30T13: 41: 00
data początkowa | 2012-04-21T13: 41: 00, 2012-06-01T13: 41: 00

To powoduje teraz problemy z moim zapytaniem brokera, ponieważ nie mogę już używać prostej logiki zapytań do pobierania pozycji wymaganych do wyszukiwania na podstawie dat.

Zanim zacznę pisać logikę C#, aby przetworzyć te rozdzielone przecinkami daty i wyszukać w oparciu o te, zastanawiałem się, czy ktoś miał podobne wymagania/doświadczenia w przeszłości i wdrożył to w inny sposób, aby zmniejszyć ilość konieczne jest parsowanie kodu i użycie kwerendy brokera w celu dokończenia wyszukiwania.

Zajmuję to na Tridion 2009, ale stosując 5,3 Broker (ze względów starszych) więc zapytanie obecnie wygląda następująco (dla pojedynczych terminach rozpoczęcia/zakończenia):

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

Każda pomoc jest mile widziane.

Źródło

2012-04-25 Mike Percival

Nigdy nie korzystałem z Brokera 5.3, czy pozwala na słowo kluczowe "IN"? –

Tak, zapytanie, które dodałem powyżej, zawiera przykłady użytego słowa kluczowego "IN", które jest świetne dla pojedynczych wartości, ale wiele wartości nie jest już przechowywanych jako daty, ale ciąg znaków rozdzielonych przecinkami (jako wartość ciągu znaków)) co oznacza, że nie mogę już wyszukiwać według daty, tak jak poprzednio. –

Tak jest, przykro mi, że tego nie zauważyłem i to i tak by mi nie pomogło, przepraszam! –

Jest to złożony scenariusz, jak będzie trzeba przejść po całej DCPs i analizowania tych ciągów do określenia, czy pasuje do kryteriów

istnieje sposób można przekonwertować metadane (oddzielone przecinkiem) w pojedynczym wartości w brokerze, ale nazwy pól muszą być różne Zakres1, Zakres2, ...., ZakresN Możesz to zrobić z rozszerzeniem instalatora, w którym zmieniasz strukturę XML pakietu i konwertujesz te łańcuchy w różnych wartości (1,2, .., n). To rozszerzenie może zająć trochę czasu, jeśli nie znasz rozszerzeń wdrażających i nie rozwiąże 100% scenariusza.

Problemem jest to, że trzeba jeszcze zastosować kilka warunków odzyskać te wartości i zawsze jest limit trzeba ustawić (wobec Użytkownika, który może dodać wartości, jakie mogą jak chce)

próbkę:

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

Prawdopodobnie najszybszym i najłatwiejszym sposobem osiągnięcia tego jest użycie pola wielowartościowego, użycie różnych pól. Rozumiem, że nie jest to najbardziej ogólny scenariusz i są implikacje dotyczące wymagań biznesowych, ale mogą uprościć rozwój.

Moje poprzednie uwagi dotyczą kontekstu używania wyłącznie API Broker, ale możesz skorzystać z wyszukiwarki, jeśli jest częścią Twojej architektury. Możesz indeksować bazę danych brokera i masować dane. Korzystanie z API Search Engine można wyodrębnić identyfikatory komponentów/Component Szablony i użyć brokera API do pobierania odpowiednia informacja

Źródło

2012-04-25 15:31:38 Miguel

Dzięki Miguel, na pewno istnieją dobre pomysły, ale myślę, że najlepsze (i najłatwiejsze do wdrożenia) mogą być używanie wielu pól, a nie wielu wartości. Wydaje się proste rozwiązanie, ale nie brałem pod uwagę. Tak długo, jak to może obsłużyć wymagania biznesowe (do potwierdzenia), bardzo prawdopodobne jest, że zastosuję to podejście. –

Cześć Mike: Cieszę się, że było użyteczne. Zalecam wykonanie szybkiego testu ze scenariuszem z wieloma polami, aby upewnić się, że działa poprawnie dla wielu zakresów dat – Miguel

prostu chciał wrócić i podać kilka szczegółów na temat I wreszcie zbliżył powinno to nikogo innego twarz ten sam scenariusz.

Zaproponowałem klientowi określoną liczbę pól (zgodnie z sugestią Miguela), ale klient nie był zadowolony z tego poziomu ograniczenia.

W związku z tym doszedłem do implementacji schematu embeddable zawierającego daty początkowe i końcowe, które dały największą elastyczność. Jednak ograniczenia w API Broker sprawiły, że musiałem bezpośrednio uzyskać dostęp do Broker DB - nie jest to idealne rozwiązanie, ale klient zgodził się na podejście do uzyskania wymaganej funkcjonalności. Oczywiście, należałoby to zmienić w przypadku ewentualnych ulepszeń w przyszłości.

Wszystkie przetwarzanie dat i dostępnych okresów zostały wykonane w języku C#, co oznacza, że wydajność rozwiązania jest całkiem niezła.

Jedną z rzeczy, które odkryłem, które spowodowały pewne problemy było to, że jeśli masz wiele wartości dla pola za pomocą osadzonego schematu (tj. W tym przypadku, wiele dat rozpoczęcia i zakończenia), wówczas dane meta są przechowywane w KEY_STRING_VALUE kolumna w tabeli CUSTOM_META . Jeśli jednak w polu znajduje się tylko jedna wartość (tj. Jedna data rozpoczęcia i zakończenia), wówczas są one przechowywane jako kolumny w kolumnie KEY_DATE_VALUE w taki sam sposób, jak w przypadku korzystania tylko z pojedynczych pól, a nie z osadzonego schematu . Wydaje się to sensownym podejściem dla Tridion, ale ma to na celu uczynienie go nieco bardziej skomplikowanym podczas pisania zapytań i kodu parsującego!

Źródło

2012-04-30 13:34:34

Format przechowywania metadanych Tridion 2009 w brokerze

Odpowiedz

Powiązane problemy