стратегия возврата JSON из канонической модели XML

Я использую шаблон конверта, а моя каноническая часть модели находится в формате XML. Я обычно возвращаю модель полностью или в краткой версии. Получение документов происходит довольно быстро, но при возврате в рамках моего вызова REST, когда мне нужно вернуть JSON в браузер, мой json: transform-to-json принимает в два раза больше версии вызова, который просто возвращает XML.

Это стратегия, чтобы также иметь каноническую модель в формате JSON, а также в конверте, или, возможно, визуализировать json в полном и сводном форматах в других документах за пределами конверта, которые не ищутся, но в основном используются при возврате Результаты? Таким образом, мне не нужно постоянно терять деньги за преобразование канонической модели в JSON.

Есть ли другие способы сделать это?


xml json marklogic marklogic-8
person TJ Tang    schedule 10.06.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Преобразование из XML в JSON должно быть относительно легким, но сам факт, что он должен что-то делать, потребует накладных расходов. Выполнение этой работы заранее определенно сэкономит время. Вы можете поместить оба формата в один и тот же конверт (хотя тогда JSON нужно будет сохранить как строку) или в другом документе, как вы предлагаете. В качестве альтернативы вы также можете сохранить его в свойствах документа. К сожалению, это также требует только XML, поэтому вы также будете хранить там свой JSON в виде строки.

В качестве альтернативы, вы профилировали преобразование, чтобы увидеть, есть ли конкретная причина, по которой оно так сильно замедляется? Использование XSLT вместо XQuery для преобразования тоже может иметь значение.

HTH!

person grtjn    schedule 10.06.2016
comment
Я просто использовал json: transform-to-json, потому что это был простой вызов, который мне не требовался. Время напрямую связано с размером XML, который необходимо обработать. Я посмотрю, как хранить различные форматы в конверте, и посмотрю, как это работает: полный xml, сводный xml, полный json и сводный json. - person TJ Tang; 10.06.2016
comment
+1 по профилированию. Решение о том, хранить ли версию JSON, в конечном итоге зависит от времени (скорости доставки) или объема (дополнительное хранилище для версии JSON). Я думаю, что для этого есть следующие варианты: 1) конвертировать при чтении (как вы это делаете); 2) сохраните другую версию (как вы предложили); 3) перейти на модель JSON; или 4) сделать конверсию на среднем уровне. Я бы сосредоточился на выполнении (1) или (3) в качестве своего первого выбора. - person Dave Cassel; 10.06.2016

arrow_upward
1
arrow_downward

json: transform-to-json имеет 3 алгоритма, оптимизированных для разных целей, и будет работать с различными компромиссами гибкости, точности и производительности.
"basic" (по умолчанию) полезно только для обратного json: transform-from-json () " full "- для сохранения максимально возможной достоверности информации, во многих случаях в обмен на формат, отличный от prety. "custom" - это ... нестандартный ... разработанный, когда формат json фиксирован или когда вы хотите контролировать вывод json за счет точной обработки подмножества XML.

Базовый и полный - самые эффективные. Однако все варианты довольно сложны и требуют полного обхода дерева узлов XML и создания дерева объектов JSON снизу вверх. В ML версии 8 это затем транслируется в собственную структуру узлов JSON. Затем при вызове REST он будет сериализован как текст.

По сравнению с прямым возвратом xml-документа vi fn: doc ("file.xml") в случае преобразования требуется как минимум на 2 порядка больше операций. Для небольших документов в вызове REST, который по-прежнему составляет небольшую часть от общего времени запроса, особенно если вызов REST сам выполнял сложную операцию, а затем возвращал небольшой результат. Ваш вариант использования кажется противоположным - возврат XML-документа напрямую обходит почти всю обработку XQuery и отправляется напрямую из внутреннего на вывод или назначается переменной.

Если это важный вариант использования для оптимизации, особенно если документы могут быть большими, то сохранение их в виде текста или двоичного файла будет намного быстрее - за счет использования большего объема хранилища. Если это только вариантное представление xml, попробуйте сохранить текст JSON как двоичный, так как это не повлечет за собой никаких накладных расходов на индексацию.

В противном случае, если вам нужно выполнить запрос по JSON, тогда в ML7, хранящемся в виде текста, вы получите простые запросы слов, а в ML8, хранящем как собственный JSON, вы получите структурированные запросы - оба с эффективной сериализацией текста.

person DALDEI    schedule 10.06.2016