Тут есть два момента. Первое, как было замечено, нативная поддержка на уровне PL+. Второе, быстродействие. При онлайн взаимодействии на первый план выходит скорость реакции системы, что, например, со встроенным парсером вряд-ли возможно. Посмотрите, например, форматы ЦФТ-интегратора - плоский одноуровневый xml.
Все вышесказанное - мое сугубо личное мнение, основанное на некотором опыте организации взаимодействия на базе xml как через файлы, так и онлайн.
Будем надеяться, что ЦФТ все-таки встроит в ИБСО нормальные средства работы с xml.
как я понял, с помощью XSD мы можем проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных (отсюда).
конечно, это хорошо, если мы делаем сложное приложение на xml (например вэб сервис). но сейчас нам требуется сделать экспорт данных в примитивный XML, стоит ли заморачиватья насчет XSD?
Тут есть два момента. Первое, как было замечено, нативная поддержка на уровне PL+. Второе, быстродействие. При онлайн взаимодействии на первый план выходит скорость реакции системы, что, например, со встроенным парсером вряд-ли возможно.
Как раз таки наоборот: оракловый парсер написан на С, поэтому скорость его работы высокая. ЦФТшные парсеры написаны на PL+ (PL/SQL), XML_DOM вроде на Яве написан (но могу ошибаться).
Если требуется загрузка объемной плоской портянки, то следует отказаться от использование DOM-модели, т.к. она будет поедать PGA, и использовать SAX-парсер DBMS_XMLSTORE.
Если говорить основываясь на опыте, то я как-то делал шлюз с OpenWay, и там грузилась избыточная и довольно ветвистая XMLка. Надо было использовать XSLT для упрощения структуры, и это накладывало необходимость использования DOM.
30Мб файлы на ура пролетали!
но сейчас нам требуется сделать экспорт данных в примитивный XML, стоит ли заморачиватья насчет XSD?
Попробуй DBMS_XMLGEN.
Вот тебе примерчег:
Код:
-- Собираем XML массива операций
declare
ctx dbms_xmlgen.ctxHandle;
cur sys_refcursor;
sOperXml XMLType; -- XML массива операций
begin
cur%open(
select arr(
.....
)
уже давно дистрибутивно можно работать через XMLDB
Вась, примерчик кинь plz.
Да и потом. Если говорить про XDB (XDK), то к пакетам dbms_xmldom, dbms_xslprocessor можно было и так обращаться. А вот конструкции XMLType, которые пишутся в селектах, PL+ спецификация, насколько я знаю, не поддерживает.
Последний раз редактировалось: maestro (Вт Фев 14, 2012 11:36), всего редактировалось 2 раз(а)
Если уж ничего кроме ваяния ручками прикрутить не получается, то можно вот так:
Код:
-- Сочинение XML c F1 XMLElement
create table srjtmp (f1 varchar2(255), f2 varchar2(255));
insert into srjtmp(f1,f2) values ('12', '22');
insert into srjtmp(f1,f2) values ('32', '32');
SELECT
XMLElement( "root",
XMLElement("f1", f1),
XMLElement("f2",
(SELECT
XMLAGG(XMLELEMENT("f1f2",
e.f1||' '||e.f2)
ORDER BY f2)
FROM srjtmp e
)
)
)
FROM
srjtmp;
самый простой и эффективный способ создания xml - через обычную строковую переменную без использования парсера/модели.
!! Не вздумайте так делать!!
Дело в том, что при создании XML стандартным парсером, выходной XML получается валидным! Разработчику нет нужды заморачиваться экранированием спецсимволов, вложенныхь XML-конструкций, кодировками и прочей херью, которая может не отвалидироваться на стороне приёмника. Стандартный парсер просто не даст Вам создать невалидный XML!
Собирать XML c F1 конкатенации в наше время - сродни каменному топору.
ИМХО, лучше потратить некоторое количество времени на изучение XML+XSD+XSLT, и затем эффективно пользоваться этими инструментами. Они дают возможность БЫСТРО создавать НАДЕЖНЫЕ приложения.
Забавно читать это в 2020, году. Особенно после проекта внедрения в одном крупном банке , в который в качестве ноу-хау была преподнесена "технология" собирания xml именно путем конкатинации с string и clob. Причем "технология" эта пришла из другого, еще более крупного банка.
Ощущение было правда как будто работаю не с каменным топором, а как будто строю мост из навоза обычной лопатой.
dnk_dz пишет:
самый простой и эффективный способ создания xml - через обычную строковую переменную без использования парсера/модели.
Самое смешное в таких наваторах, это как они решают обратную задачу, по разбору xml. Тут что-то самый простой способ без использования парсера/модели не работает и они уже начинают слушают взрослых дядей.
Последний раз редактировалось: De Mian (Чт Апр 23, 2020 10:16), всего редактировалось 1 раз
Чт Апр 23, 2020 10:12 Re: Простой разбор документов XML
Полезность: Нет оценки
dnk_dz пишет:
Может, кому пригодится.
Недавно столкнулся с проблемой разбора различных видов XML документов. После написания километров кода для разбора каждого XML документа в отдельности, пришел к мысли, что в таком темпе я буду долго писать обработку десятка XML документов. А если нужно будет добавить обработку еще двадцати? В общем, пришли к мысли, что проще XML выгрузить в PL/SQL таблицу и ее уже обрабатывать. Так оказалось гораздо проще.
Далеко продвинулся в этой теме ?
Аналогичные сомнения терзали и меня. В итоге я в цфт запилил механизм. Описываю структуру, описываю какие поля читаются, а какие пишутся. Некий декларативный подход, когда я описываю что мне нужно, но не как это делать. А "как это делать" определяется подключением движка. И в итоге "декларация" компилируется либо в процедуры для работы с xml, либо для работы с cit_xml ,ну и json.
Подробней тут
Но сейчас другая проблема встала. Огромные xsd. Ищу решение по автоматическому перекладыванию xsd в описание структур на pl+/plsql. Тема парсинга/сбора этих огромных структур решена уже(выше написал), но вот просто описание структур соответствующих элементам xsd, оказывается тоже рутинной и монотонной задачей. Нужна автоматизация.
Просьба помочь, может кто сталкивался с такой проблемой ....
Пытаюсь распарсить XML файл, содержащий знаки (2 байта)
с помощью парсера XML_DOM
&xml.parseClob(parser, doc);
выходит ошибка
ORA-20100: Error occurred while parsing:
Fatal Error at file LOB, line 1, char 39
An exception occurred! Type:UTFDataFormatException, Message:invalid byte 1 (?) of a 1-byte sequence.
: ORA-06512: на "IBS.XRC_XMLPARSER", line 40
ORA-06512: на "IBS.XRC_XMLPARSER", line 256
ORA-06512: на "IBS.Z$RUNTIME_XML_DOM", line 61
ORA-06512: на "IBS.Z$RUNTIME_LIB_XML_PL", line 86
Кто нибудь ранее парсил XML содержащие знаки занимающие 2 байта, просьба привести примеры если есть?
Парсер не понимает UTF8 кодировку ? Или проблема в чем то другом ? Может парсер XML_DOM не тот использую ? Поискал в инете, но ничего не нашел толкового.
Может это баг Oracle ?
Пытаюсь распарсить XML файл, содержащий знаки (2 байта)
с помощью парсера XML_DOM
Может парсер XML_DOM не тот использую ? Поискал в инете, но ничего не нашел толкового.
Может это баг Oracle ?
XML_DOM. Это не ораклянная библиотека. Это реализация парсера Xerces от ЦФТ.
Попробуй XML_DB . Это обертка над dbms_xmldom.
Отпишись о результате обязательно. Тоже вопрос интересует.
Опытным путем , выявлено что такая ошибка, как правило, возникает когда кодировка тела XML не соответствует кодировке в заголовке XML :
<?xml ... encoding=???? ?>
Провертьте, парсер читает кодировку из заголовка и дальше пытается разбирать сообщение в указанной кодировке????
Теперь нужно понять как работает парсер xerces от фирмы ЦФТ на предмет проверки кодировки в заголовке и в теле XML.
Часовой пояс: GMT + 3 На страницу Пред.1, 2, 3След.
Страница 2 из 3
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB
О проекте
Поиск
Отзывы
Регистрация
Вход
