Рабочее
По зиме-началу весны довелось мне кодить обмен с 3PL складом. Туда-сюда гонялись JSON-ы, мне их приходилось парсить. Коллеги подогнали движок, который разбирал JSON, укладывал во временную табличку, а из нее я уже распихивал данные по боевым таблам. В новом проекте самодельный парсер меня подвел и не смог работать с определенным интерфейсом.
Встал вопрос, что делать, поскольку решение себя скомпрометировало. Возникла мысль парсить JSON на SQL-сервере. Идея смотрится красиво.
Джоб в NAV бежит по новым записям в очереди и, в зависимости от типа данных, в режиме обработки ошибок стартует хранимую процедуру на скуле, передавая ей номер текущей записи. Хранимка вытаскивает из BLOB поля лежащий в нем JSON, парсит его его содержимое и записывает в нужное место.
На бумаге все классно. В реале я разобрался с нуля со скульным парсером часа за 2. Еще через час у меня уже были куски кода, которые возвращали все три рекордсета, которые должны были улечься ко мне в базу. Проблема была вытащить данные непосредственно из BLOB поля. И Гугл и Яндекс едва ли не в каждом результате выдачи убеждали меня, что получить содержимое текстового файла из BLOB-а можно путем двойной конвертации: BLOB --> VARBINARY(MAX) --> NVARCHAR(MAX). Я попробовал -- у меня на выходе нечитабельная хня. Попробовал передать хранимке файл из NAV в виде BIGText, не прокатило по типу данных параметра в ADODB. Орнул в чат разработчиков в компании, мол, посоны, спасайте! Ну не может же быть, что бы никто не добывал скулем xml или json из BLOB для парсинга им же... гробовая тишина в ответ. Один чел ответил, но тоже слегонца мимо, хотя и его идею я проверил.
Через 11 рабочих часов после начала этой войны, я наткнулся на ма-а-а-а-аленькую ремарочку, в недрах какого-то форума, что конвертация BLOB --> VARBINARY(MAX) --> NVARCHAR(MAX) работает только в том случае, если NAV хранит данные в этом поле в несжатом виде. Я лезу в структуру таблы в NAV и вижу там свойство искомого поля Compressed = TRUE. Ставлю FALSE, сохраняю таблу, запускаю скрипт и вот оно! ОГРАЗМ!!!!
Мегабайтный json распарсился и всосался в базу примерно за секунду. 12 часов войны на новом ТВД. С нуля. Кто молодец? Я молодец )))
Теперь понятно, как NAV (старый-древний, родной и ламповый, не забывающий сюрпризы подкидывать) работает. В зависимости от флага Compresed в свойствах поля, движок NAV или постит в BLOB файл как есть, или постит его уже как результат работы какого-то внутреннего архиватора. При вынимании данных из такого поля алгоритм аналогичный, т.е. или данные возвращаются как есть, или уже прошедшие внутренний NAV-овский unzip. Короче, значение свойства этого поля на юзеров или кодеров NAV не влияет ваааще. От него зависит то, как именно хранятся данные на скуле, ну и размер таблы на диске, ессно. Я искал инфу по алгоритму сжатия, нашел только сторонние функции от энтузиастов в виде внешних dll, которые никто на боевой сервак в серьезной конторе в здравом уме ставить не станет.
В общем, получив вполне себе работающий интерфейс, я, ну типа исправился за косяк, доложился начальству. В итоге бурного обсуждения все пришли к выводу, что парсер надо делать на WEB-сервисе, с использованием библиотеки, которую юзает наш новый хозяин, этот интерфейс на ней будет делать другой человек, а я потом посмотрю на его решение и буду клонировать его для других интерфейсов.
12 часов непрерывного самоотверженного рытья в абсолютно новой области идут нахрен. Жаль. У меня получилось красиво.
Встал вопрос, что делать, поскольку решение себя скомпрометировало. Возникла мысль парсить JSON на SQL-сервере. Идея смотрится красиво.
Джоб в NAV бежит по новым записям в очереди и, в зависимости от типа данных, в режиме обработки ошибок стартует хранимую процедуру на скуле, передавая ей номер текущей записи. Хранимка вытаскивает из BLOB поля лежащий в нем JSON, парсит его его содержимое и записывает в нужное место.
На бумаге все классно. В реале я разобрался с нуля со скульным парсером часа за 2. Еще через час у меня уже были куски кода, которые возвращали все три рекордсета, которые должны были улечься ко мне в базу. Проблема была вытащить данные непосредственно из BLOB поля. И Гугл и Яндекс едва ли не в каждом результате выдачи убеждали меня, что получить содержимое текстового файла из BLOB-а можно путем двойной конвертации: BLOB --> VARBINARY(MAX) --> NVARCHAR(MAX). Я попробовал -- у меня на выходе нечитабельная хня. Попробовал передать хранимке файл из NAV в виде BIGText, не прокатило по типу данных параметра в ADODB. Орнул в чат разработчиков в компании, мол, посоны, спасайте! Ну не может же быть, что бы никто не добывал скулем xml или json из BLOB для парсинга им же... гробовая тишина в ответ. Один чел ответил, но тоже слегонца мимо, хотя и его идею я проверил.
Через 11 рабочих часов после начала этой войны, я наткнулся на ма-а-а-а-аленькую ремарочку, в недрах какого-то форума, что конвертация BLOB --> VARBINARY(MAX) --> NVARCHAR(MAX) работает только в том случае, если NAV хранит данные в этом поле в несжатом виде. Я лезу в структуру таблы в NAV и вижу там свойство искомого поля Compressed = TRUE. Ставлю FALSE, сохраняю таблу, запускаю скрипт и вот оно! ОГРАЗМ!!!!
Мегабайтный json распарсился и всосался в базу примерно за секунду. 12 часов войны на новом ТВД. С нуля. Кто молодец? Я молодец )))
Теперь понятно, как NAV (старый-древний, родной и ламповый, не забывающий сюрпризы подкидывать) работает. В зависимости от флага Compresed в свойствах поля, движок NAV или постит в BLOB файл как есть, или постит его уже как результат работы какого-то внутреннего архиватора. При вынимании данных из такого поля алгоритм аналогичный, т.е. или данные возвращаются как есть, или уже прошедшие внутренний NAV-овский unzip. Короче, значение свойства этого поля на юзеров или кодеров NAV не влияет ваааще. От него зависит то, как именно хранятся данные на скуле, ну и размер таблы на диске, ессно. Я искал инфу по алгоритму сжатия, нашел только сторонние функции от энтузиастов в виде внешних dll, которые никто на боевой сервак в серьезной конторе в здравом уме ставить не станет.
В общем, получив вполне себе работающий интерфейс, я, ну типа исправился за косяк, доложился начальству. В итоге бурного обсуждения все пришли к выводу, что парсер надо делать на WEB-сервисе, с использованием библиотеки, которую юзает наш новый хозяин, этот интерфейс на ней будет делать другой человек, а я потом посмотрю на его решение и буду клонировать его для других интерфейсов.
12 часов непрерывного самоотверженного рытья в абсолютно новой области идут нахрен. Жаль. У меня получилось красиво.
