Проблема после обновления eXist 2.2 до 4.5 с конкретными запросами - PullRequest
0 голосов
/ 29 декабря 2018

Итак, в моем предыдущем посте я рассмотрел много вещей об индексировании, которые я узнал при обновлении с eXist-db 2.2 до 4.5.

Теперь у меня есть эта запутанная проблема, которую я могу легко показать на экранах, что мне нужен кто-токомментировать, чтобы помочь мне понять.Я могу создать исправление для изменения каждого XML в БД, но это кажется ... ну, неправильно.

Я портировал большую базу данных, включая большую базу данных клиентов.Подписки клиентов хранятся в виде файлов XML.Я экспортировал старую БД и импортировал все это в новую БД.

Пример данных в старой базе данных через oXygen выглядит следующим образом:

enter image description here

Если я не касаюсь чего-либо еще, если я использую oXygen для просмотраXML-файл в новой БД Я вижу это (я вырезаю кучу контента, который является частным), но на самом деле в этом нет ничего плохого, просто нет красивой печати, как говорится:

enter image description here

Итак, теперь я делаю простой запрос по всей этой коллекции следующим образом:

xquery version "3.0";
let $colcust := '/db/EIDO/data/Customers'
let $docnum := 'A01'
return count(collection($colcust)/customer/portal/specialty/document[@docnum = $docnum])

Я получаю 692, что совершенно правильно.Есть 692 случая этого.Прекрасный результат.

Теперь я хотел бы внести некоторые изменения в индекс, чтобы улучшить это.Поэтому я создаю это:

<collection xmlns="http://exist-db.org/collection-config/1.0">
    <index>
        <range>
            <create qname="user_id" type="xs:string"/>
            <create qname="territory" type="xs:string"/>
            <create qname="@name" type="xs:string"/>
            <create qname="@docnum" type="xs:string"/>
            <create qname="@subscribed" type="xs:string"/>
            <create qname="lang" type="xs:string"/> 
            <create qname="title" type="xs:string"/>
            <create qname="type" type="xs:string"/>
        </range>
    </index>
</collection>

Я помещаю его в / system / config в нужном месте.И я выполняю точно такой же запрос ... Я получаю "0" не 692, а 0 хитов.

ОК, поэтому я думаю, что что-то не так, и я открываю один из реальных файлов XML, и я вижу, что все переводы строки удаленынет красивой печати.Поэтому я использую oXygen, чтобы красиво напечатать его, чтобы я мог изучить пути, чтобы убедиться, что я не сделал что-то не так.Я действительно нажал «сохранить», ничего не меняя.Я снова запускаю запрос и упс!Я получаю «1», файл, который я только что напечатал.Я открываю еще один, и я довольно печатаю XML и сохраняю, и я получаю 2. В недоумении я пытаюсь снова и получаю 3, а затем 4.

Я удаляю collection.conf, и я запускаю, и я все еще получаю 692Я положил его обратно, и теперь я получаю 4.

Я вернулся к ZIP-архиву, созданному для резервной копии, и взломал его, и, конечно же, все файлы убрали свои переводы строки.Так что это именно то, что было импортировано.

Итак, вопрос в том ... почему перечисленный выше collection.conf изменяет результат простого запроса, который я разместил?Или, может быть, почему XML, хранящийся в БД без красивой печати, кажется, нарушает индексацию?

Возможно, я мог бы просто создать xQuery, который будет применять XSL-идентификатор ко всем XML-файлам, но для меня это ужасный хак.Это известное поведение?Если да, есть ли какие-либо настройки резервного копирования / восстановления, которые этого не делают или?

1 Ответ

0 голосов
/ 29 декабря 2018

Я отвечу на свой вопрос по этому вопросу.Очевидно, что-то было сломано в индексации каким-то образом.Я принял к сведению время индексации при выполнении переиндексации, и оно показалось мне ужасно быстрым.Хотя приложение Monex показало индексы на месте.Я вырезал все в collection.xconf, кроме @docnum и переиндексировал, и это заняло гораздо больше времени.Поиск дал правильный результат.

Затем я восстановил оставшуюся часть collection.xconf и переиндексировал, и снова это заняло гораздо больше времени и дало правильный результат.Документы, которые я отредактировал, были переиндексированы, поэтому они были сбиты.

...