Поиск без учета регистра с eXist-db - PullRequest
2 голосов
/ 02 января 2011

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

Прежде всего, в моем классе Java я выполнил довольно простой анализ веб-страницы:

title=(String)results.get("title");
doc = docBuilder.parse("http://" + server + ":" + port + "/exist/rest/db/wb/xql/media_lookup.xql?" + "&title="  + title);

Этот оператор Java ссылается на файл XQuery "media_lookup.xql", который хранится на локальном хосте, и единственный передаваемый нами параметр - это строка "title".

Во-вторых, давайте посмотрим на этот файл XQuery:

$title := request:get-parameter('title',""),

$mediaNodes := doc('/db/wb/portfolio/media_data.xml'),
$query := $mediaNodes//media[contains(title,$title)],

Тогда он оценит этот запрос. Этот XQuery получит параметр «title», передаваемый из нашего Java-класса, и запросит xml-файл «media_data», хранящийся в базе данных, который содержит группу медиа-узлов с узлом элемента «title». Как вы можете ожидать, этот простой запрос будет соответствовать тем узлам мультимедиа, чей элемент title содержит подстроку значения строки title. Поэтому, если наш заголовок - «Chi», он вернет медиа-узлы, заголовок которых может быть «Chicago» или «Chicken».

Запрос на уточнение, отправленный клиентом, гласит, что НЕТ чувствительности к регистру. Интуитивно понятный способ - изменить оператор XQuery, используя в нем строчную функцию, например:

$query := $mediaNodes//media[contains(lower-case(title/text(),lower-case($title))],

Однако возникает вопрос: этот измененный запрос приведет к переполнению памяти на моем компьютере. Так как мой "media_data.xml" довольно большой и содержит тысячи миллионов медиа-узлов, Я предполагаю, что функция в нижнем регистре () будет запускаться для каждой записи, что приведет к сбою машины.

Я разговаривал с опытным программистом XQuery, и они думают, что я должен использовать индекс для решения этой проблемы, и я обязательно изучу это. Но до этого я просто публикую эту проблему здесь, чтобы получить другие идеи или предложения, как вы думаете, может ли помочь какой-то другой способ? например, могу ли я настроить оператор синтаксического анализа Java, чтобы реализовать регистрозависимость? Так как я думаю, я видел, что некоторые люди делали конкатенацию строк, используя «содержит». в Java перед передачей на сервер.

Приветствуется любая идея или помощь.

Ответы [ 2 ]

2 голосов
/ 02 января 2011

Запрос уточнения, отправленный клиентом, гласит, что не должно быть никакой чувствительности к регистру.Очень интуитивно понятный способ - изменить оператор XQuery, используя в нем функцию нижнего регистра, например:

$query := $mediaNodes//media
            [contains(lower-case(title/text(),lower-case($title))], 

Однако возникает вопрос: этот измененный запрос запустит мою машинув переполнение памяти.Поскольку мой «media_data.xml» довольно большой и содержит тысячи миллионов медиа-узлов, я предполагаю, что функция нижнего регистра () будет запускаться для каждой записи, что приведет к сбою машины.

Такие опасения неоправданны.

Любая вменяемая реализация XPath использует автоматическую память для своих функций.Это означает, что память, необходимая для оценки конкретного предиката, включая результат lower-case(), освобождается (в языках без сборки мусора) или перестает ссылаться и готова к сборке мусора сразу после оценки предиката.

0 голосов
/ 02 января 2011

Индекс таблицы, вероятно, не является решением, так как отсутствие индекса замедлит процесс, но не вызовет переполнение памяти.

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

Чтобы сохранить некоторую обработку, вы можете сделать кейс в $product перед запросом.

Вы можете удалить амперсанд в своем URL, я не уверен, что все веб-серверы правильно анализируют ? & .

...