Где хранить данные поиска в Adobe CQ

Question

За последние 3 года мы увеличили использование Adobe CQ. Мы начали с использования 5.4, где несколько разработчиков (по рекомендации Adobe Consultants) хранили несколько «таблиц» поиска в/var // node. Они были использованы в качестве хранилищ поиска для таких компонентов, как почтовые индексы, идентификаторы сайтов и т. Д.

Теперь мы отважились на CQ 5.6, и у нас возникли трудности с доступом к этим данным на нашем экземпляре издателя. Автор отлично работает, но когда издатель пытается получить доступ к данным, получается 404. Некоторое время назад у нас были некоторые другие консультанты, которые упоминают, что хранение данных в/var не было хорошей идеей, но я не помню, почему что.

Есть ли рекомендованное место для хранения общих данных поиска, к которым будут иметь доступ к нескольким компонентам, страницам или другим объектам?

Заранее благодарю вас за помощь.

Answer 1

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

Сохранение версий и стопка другой информации хранится там, поэтому она не должна подвергаться воздействию клиентов.

/etc - это место, которое было оставлено открытым на диспетчере в целом, поэтому логическое место размещения информации поиска, если оно принадлежит как часть SDLC, находится в этом месте.

Если поисковые запросы должны быть авторизованы, было бы разумнее разместить его в каталоге/content, который, если вы делаете что-либо, что включает в себя многопоточность, вписывается в стратегию перезаписи. Кроме того, если различные арендаторы имеют доступ к тем же данным поиска, т.е.

http://www.mysite.com/mypage.html goes to /content/mysite/mypage and 
http://www.anothersite.com/anotherpage.html goes to /content/anothersite/anotherpage, 

правило перезаписи может быть использован для общего расположения. , например.

www.mysite.com/lookups/postcodes.json /content/lookups/postcodes 
www.anothersite.com/lookups/postcodes.json /content/lookups/postcodes 

Надеюсь, что имеет смысл.

Answer 2

/etc - хорошее место для хранения общих данных, которые отделены от частей дисплея CQ. Например, CQ использует /etc/blueprints для хранения информации о том, что использует LiveCopy. Автор и издатель имеют местоположение /etc, так что это не проблема. CQ может делать смешные вещи до /var, поэтому я не уверен, почему это было рекомендовано в качестве места хранения.

Answer 3

Я не уверен, что этот вопрос так же прост, как «где его положить?». Как ваши компоненты/страницы запрашивают эту информацию? Это через звонки AJAX? Если это так, вы действительно должны получить доступ к нему через Sling GET Servlet, который создает данные как JSON. Если вы говорите о доступе к этим данным через диалоговые окна экземпляров экземпляра, местоположение не должно иметь значения, потому что обычно ваш экземпляр автора довольно открыт. Если вы говорите о доступе к этой стороне сервера данных, как часть рендеринга компонента (в JSP или его базовом классе), вам определенно не нужно перемещать его нигде, потому что JcrResourceResolver имеет к нему доступ.

Обычно я не ставил что-либо под/var (это системная часть дерева), но решение заключается не в выборе другого произвольного местоположения, а в том, чтобы вы могли его разоблачить. Решение заключается в том, чтобы понять, где вам нужно получить доступ к этой информации, а затем разоблачить ее соответствующим образом для этого случая. Имеют смысл?

Я был бы рад предоставить вам больше информации, если вы могли бы предоставить более подробную информацию о том, как вы пытаетесь получить данные.