Управляемый документ не работает в MarkLogic 10 после xdmp:document-insert
- Впервые управляйте документом с помощью
dls:document-insert-and-manage - Обновите тот же документ, используя
xdmp:document-insert Документ теряется из коллекции последних версий dls
cts:search(/scopedIntervention/id , dls:documents-query())Управление документом в первый раз
<scopedIntervention> <id>someId12345</id> <scopedInterventionName> First Name </scopedInterventionName> <forTestOnly> true </forTestOnly> <inactive> true </inactive> </scopedIntervention>)``` **Document inserted with versioning**Убедитесь, что документ присутствует в последней коллекции документов
cts:search(/scopedIntervention/id , dls:documents-query())Документ присутствует в управляемой последней коллекции
Обновите тот же документ
<scopedIntervention> <id>someId12345</id> <scopedInterventionName> Updated Name </scopedInterventionName> <forTestOnly> true </forTestOnly> <inactive> true </inactive> </scopedIntervention>)``` **Update document to same URI using xdmp:document-insert**Снова проверьте наличие документа или НЕТ в последней коллекции документов.
cts:search(/scopedIntervention/id , dls:documents-query())Документ НЕ присутствует в последней управляемой коллекции (утерян из коллекции)
После применения пакета DLS с использованием следующего шага обновления тот же документ отображается в списке. ``xquery версии "1.0-мл"; пространство имен модулей импорта dls = "http://marklogic.com/xdmp/dls" в "/MarkLogic/dls.xqy";
dls:set-upgrade-status(fn:false()),
dls:start-upgrade(),
fn:doc("http://marklogic.com/dls/upgrade-task-status.xml"),
dls:latest-validation-results(),
dls:set-upgrade-status(fn:true())```
Ответы 2
- Update the same document using xdmp:document-insert
Скорее всего, на этом этапе вы удаляете последнюю коллекцию DLS. Кроме того, при этом история версий не сохраняется.
Вместо использования xdmp:document-insert вы должны использовать dls: документ-проверка-обновление-регистрация .
Вы можете попробовать xdmp:document-insert($uri, $document, xdmp:document-get-permissions($uri), xdmp:document-get-collections($uri)) . Однако при этом вы не сохраняете историю версий. Так зачем вы вообще заморачиваетесь с DLS?
Пользовательские библиотеки приложений, о которых я говорю, уже работают вживую. Таким образом, внесение изменений с xdmp:document-insert на dls:document-checkout-update-checkin требует тщательного тестирования каждого и каждого углового случая приложения. Будет проверять, сколько изменений требуется для этого нового изменения.
@IAM Если вы работаете с сотрудником MarkLogic или у вас есть возможность связаться с кем-то, знакомым с вашим проектом, я настоятельно рекомендую это. Похоже, что вы можете просто полностью избавиться от DLS или неправильно передавать коллекцию с помощью xdmp:document-get-collections. Я определенно не стал бы подходить к производственным изменениям легкомысленно без тонны испытаний.
Роб С., спасибо за ответ. Теперь у меня возникла новая проблема с документом, относящимся к управляемой версии. Вот новая тема stackoverflow.com/questions/57206843/…
Пожалуйста, прочитайте до конца. Если вы НЕ выполняли обновление DLS для обновленной версии ML, ОСТАНОВИТЕСЬ СЕЙЧАС и следуйте инструкциям по обновлению. Если этого не сделать, DLS останется в нестабильном состоянии, а любые другие ваши действия значительно усложнят ремонт.
+1 Роб. @IAM, независимо от того, «работало» ли оно или казалось, что оно «работает» в V7, dls не была предназначена для обработки случая, который вы описываете. Архитектура DLS зависит от инкапсуляции всех изменений в документах в рамках семантики возврата/выдачи. Обходя это, вы могли бы также полностью обойти DLS, потому что он не будет работать. Тот факт, что он «работал» в V7, является неправильным, возможно, он не вел себя неправильно так, как это заботило ваше приложение, или ваш код мог по совпадению выполнять достаточно похожую работу с внутренними компонентами. Возможно, вам повезет, и вы найдете способ сделать это снова, но я рекомендую вам подумать о том, как работать в рамках поведения определения библиотеки или реорганизовать те части вашего кода, которые не являются «дружественными к DLS», чтобы работать между проверкой. /checkin windows -- не все обновления должны проходить по схеме checkout-update-checkin -- вы можете оформить -- сделать что угодно -- затем зарегистрироваться.
Как обходной путь миграции вы МОЖЕТЕ использовать функции обновления, добавленные в dls на постоянной основе.
См. https://docs.marklogic.com/dls:старт-обновление
В версии 9 (я полагаю) во внутренние компоненты DLS были внесены существенные изменения без обратной совместимости, которые требуют запуска этого кода. один раз
Предполагалось, что обновление на месте от предыдущего DLS до текущего. Однако код также может работать на постоянной основе, в зависимости от деталей того, что именно делает код вашего приложения, о чем код DLS не знает.
«Новый» код DLS добавляет внутреннюю коллекцию для оптимизации распространенного случая поиска «последних» документов — если его удалить, эти документы не будут отображаться при поиске DLS (для «последних»).
Вы упомянули, что ваш код — это «сценарии миграции» -> Если они переходят с V7 на V10, вы можете запустить свой код до для обновления V10, затем запустить обновление V10, а затем запустить dls-upgrade. После этого документы должны быть в хорошем состоянии, пока вы не сделаете ничего другого, что не является определенным поведением для управляемых документов.
В MarkLogic 7
xdmp:document-insertсохранить управляемый документ в коллекции. У меня есть куча скриптов миграции и библиотек xqy, которые я планирую перенести на MarkLogic 10. Итак, есть ли альтернатива заменеdmp:document-insertнаdls:document-checkout-update-checkin? Альтернативный вариант в том смысле, что не требуется вносить изменения в существующую библиотеку xqy.