parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Пжждите, а че со встроенным классом xdoc/xnode?

Watcher 02.12 14:20

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

Но... коль уж прозвучал перенос таких операций на сторону БД,
то чем хуже встроенные классы xdoc/xnode, реализующие полноценный XPath (судя по документации?)

Вроде беглым взглядом там какие-то... и селекты и search-namespaces с аргументом в виде хеша.

Понятно, что сам XML-вид нам нафиг не надо...
Но сами то xdoc/xnode-объекты наверняка в хешоподобном виде в памяти храняться,
и ожидается, что к ним реализованы более/менее эффективные алгоритмы выборки.

Т.е. перефразируя - не проще ли обёртку написать,
реализующую загрузку хеша в объект xdoc, и обратно (если нужен конечный результат).

Т.е. будет уже не нативный объект hash, а "перегруженный" или отдельный класс,
а ля metahash, (если мы уже четко решили что в этих структурах мы будем лукапить по деревьям), и который все основное время оперирует в формате xdoc/xnode,
реализуя сподручные методы как у обычного hash

Оверхед не должен быть таким уж критичным в 2019ом, тем более если прикинуть альтернативу в виде переноса на БД или полноценную реализацию для класса хеш средствами парсера...

Впилить отдельно для json, вполне конструктивное предложение.