Здравствуйте, Sinclair, Вы писали:
TK>>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. S>Тут мне буквально позавчера рассказывали про маньяков, которые парсили 60000 килобайт XML (само собой, приезжающего с клиента) в процедуре на MS SQL. И ничего, работает.
Я срашивал про то, как распарсить уже существующий XML. Тот, что лежит уже лежит в табличке (мне показалось, что написано про это было достаточно ясно — на всякий случай выделил жирным). Распарсить XML приезжающий с клиента — ума много не надо и, про это речь не идет.
TK>>Не набросаешь примерный код на T-SQL? S>Гм. А у нас разве статей на эту тему мало?
Гм. А можно точную ссылку? Мне тоже читать лень.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, VladD2, Вы писали:
ГВ>>О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках? VD>Они там не нужны. Это конфиг а не скриптовый файл.
А вот он и пойнт. "Не нужны" на самом деле означает: "Как правило, не нужны", а если ещё точнее, то "мне не не приходилось сталкиваться с...". Идея понятна?
ГВ>>sic! Семантика Янусовых настроек легко аппроксимируется статичной структурой данных. eao197 приводит пример куда как более сложной ситуации. VD>IT тут правильно сказал, что товарищь слишком усложняет. Ну, да и условия можно приклеить на атрибутах. Вот только редактировать такой конфиг программно уже вряд ли удастся.
Вот в том-то и дело. Так что, всё зависит от способа использования. "Слишком" там усложнено или "не слишком" — вопрос второстепенный в данном случае.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinclair, Вы писали:
E>>>Следовательно, конфиги лучше писать на C#. S>>Ну, в частности именно такой выбор сделан в WinForms. В отличие от, например, Delphi, где форма описывается внешним ресурсом, в .Net форма сериализуется прямо в код.
VD>Вот в Авалоне МС уже забил на эту идею и использует банальный ХМЛ.
Тоже не панацея. Если у меня свой контрол, куда мне схему подавать для валидации, и ведь ее еще делать надо.
E>>Ну и насчет редакторов можно поспорить -- хорошо, когда они есть. GZ>У меня клиенты просто писают кипятком, когда открывают IE и у них показывается строчка что сделано неправильно. Схему они не редактируют, а понять сам xml и как его редактировать, чрезвычайно легко.
Здравствуйте, Igor Sukhov, Вы писали:
E>>>Ну и насчет редакторов можно поспорить -- хорошо, когда они есть. GZ>>У меня клиенты просто писают кипятком, когда открывают IE и у них показывается строчка что сделано неправильно. Схему они не редактируют, а понять сам xml и как его редактировать, чрезвычайно легко.
IS>клиенты = пользователи ?
IT отделы. Пользователя не стоит унижать такими подробностями как редактирование конфигурационного файла.
Здравствуйте, TK, Вы писали:
TK>Лучше тот, который выбран на основе конкретных use cases. Говорить же, что XML это серебряная пуля — не верно. Их не бывает.
А кто говорит о панацеях? Это банальность. Думать нужно всегда. Но тут речь о другом. Тут речь о наклепывании своих самопалов и полном забивании на стандартные решения. А прикрывается это особенностями использования. Хотя на поверку оказывается, что все же просто хотелось сделать велосипед.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, TK, Вы писали:
TK>За исключением того, что 2005 еще не вышел, что в 2000 использовать тип TEXT можно только в качестве параметра SP (т.е распарсить XML можно только в том случае, если его передали из вне), то все замечательно.
И что мешает скормить результат запроса хранимке или функции?
TK>хм. ну, покажи пример кода который распарсит мне XML хранящийся в поле типа TEXT...
У меня на машине уже и MSSQL 2000 нет. Даже попробовать не на чем. Так что это к Мерлу. Думаю он тебе в два счета сбацает.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
VD>>CheckCsFile и MakePathLoverCase результат декомпозиции. Это часть кода класса вынесенная из больших функций при рефакторинге чтобы не загромождать код и упростить восприятие. CheckCsFile и MakePathLoverCase вещи сугобо спефические и тут им самое место.
Ш>Им самое место не в классе Compiler, а в коллекции свободных функций-утилит для работы с именами фоайлов.
С одной стороны их конечно можно было вынести в отдельный класс. Но бездумное запихивание всего в такие классы приводит к каши в них. В даном случае CheckCsFile спицифичен и использовать его где-то щее нельзя. Так что пусть он лучше останется скрытым методом в этом классе. В интерфейсе он не присуствует. Код не загромаждает (мелкий слишоком). MakePathLoverCase наверно можно было бы выносить смело. Но опять таки нигде больше он не нужен. А до тех пор заниматься его вынесением нет смысла. Пусть будет деталями реализации. В интерфейсе его опять женет.
VD>>GetProjectFiles вообще часть интерфейса класса. Класс используется в том числе и для загрузки проектов в визульных утилитах.
Ш>То же самое -- свободная функция-утилита для извлечения списка файлов из файла проекта.
А вот тут извини. Если два первых метода в общем-то по барабану где держать, то здесь вопрос уже идеологический. Этот меотод связан с этим классом логически. Человек использующий компилятор будет интуитивно искать этот метод именно в этом классе, а не черти знает где. В данном случае можно говорить только о вынесении реализации вынимания содержимого проектных файлов. Может это и стоит сделать. Но в интерфейсе данный метод просто обязан остаться. Иначе люди будут тратить время на писки или вообще наклпают свой вариант.
К тому же этот метод завязан (косвенно) на свойства компилятора. Венеси его и прийдется транслировать все их в другой класс. Повторно использовать этот код не нужно. Так что получается просто лишняя работа ради чистого искуства. Реальной декомпизиции при этом все равно не будет.
ЗЫ
В общем, конечно можно поспорить на счет того нужно выносить эти методы куда-то или нет. Но если сравнить этот класс с Синтилой, то не думаю, что он проиграет. Тут ПК уж явно пересторался.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2, Вы писали:
ГВ>>>О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках? VD>>Они там не нужны. Это конфиг а не скриптовый файл.
ГВ>А вот он и пойнт. "Не нужны" на самом деле означает: "Как правило, не нужны", а если ещё точнее, то "мне не не приходилось сталкиваться с...". Идея понятна?
Какое правило? Ты что спросил? " И где там выражения" Где там? В Янвсе?
Вот тебе и ответили "Они там не нужны."
ГВ>Вот в том-то и дело. Так что, всё зависит от способа использования. "Слишком" там усложнено или "не слишком" — вопрос второстепенный в данном случае.
К сожалению не зависит. Просто берется и делается сапопал на каждый чих. Потом нчинается прикрывание способами использования, тем что ХМЛ мордой не вышел, парсеры не находятся, кокос не ростет.
Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, TK, Вы писали:
TK>>Лучше тот, который выбран на основе конкретных use cases. Говорить же, что XML это серебряная пуля — не верно. Их не бывает.
VD>Но тут речь о другом. Тут речь о наклепывании своих самопалов и полном забивании на стандартные решения. А прикрывается это особенностями использования. Хотя на поверку оказывается, что все же просто хотелось сделать велосипед.
Именно, что хотелось, т.к. формат уж больно понравился. И я до сих пор думаю, что для конфигов он удобнее, чем XML.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне? VD>Именно по этому я тебе и говорил, что тебе прийдется потратить год, чтобы изучить дотнет в той мере, чтобы не удивляться таким примитивным вещам.
VD>Если объяснять на пальцах, то все просто... Описание классов в сборках. Если нужно его прочесть, то сборка просто динамически подгружается. Далее форматер читает информацию и можепт поднять или сериализовать любой объект. Сам объект ему по большому барабану. А технология называется рефлекшон. VD>
Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>>>О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках? VD>>>Они там не нужны. Это конфиг а не скриптовый файл. ГВ>>А вот он и пойнт. "Не нужны" на самом деле означает: "Как правило, не нужны", а если ещё точнее, то "мне не не приходилось сталкиваться с...". Идея понятна?
VD>Какое правило? Ты что спросил? " И где там выражения" Где там? В Янвсе? VD>Вот тебе и ответили "Они там не нужны."
Хорошо, я не совсем корректно сформулировал. Для Януса — не нужны. Но как из этого следует, что они не нужны и для случая, который описал eao197?
VD>Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай.
Хм. А каковы основания для подобного утверждения? Я вот, например, считаю наоборот. А то, что IT кажется, что eao197 "всё усложняет" — очень слабый аргумент.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Вся проблема в том, что как правило, закодировать саму сериализацию куда как проще, чем определиться с тем, что именно хранить, зачем хранить и как и когда читать/писать. А закодировано это в три строки или в десять — ну никакой разницы: ни в разработке, ни в сопровождении. VD>Да, я и не подумал, что у людей бывают стль серьезные проблемы.
Это и есть основные проблемы. Просто их принято не замечать.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
ГВ>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
E>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать.
А зачем тогда отправлять? Только ради того, чтобы отправить назад?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, eao197, Вы писали:
ГВ>>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
E>>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать.
ГВ>А зачем тогда отправлять? Только ради того, чтобы отправить назад?
это необходимо.
Еще один случай, когда нужно сериализовать все обратно, это когда между клиентом и сервером устанавливается еще один компонент, про который ни клиент, ни сервер знать не должны. Такими компонентом может быть маршрутизатор (разные типы запросов на разные сервера), балансировщик нагрузки (выбор наименее загруженного сервера для обработки запроса), сборщик статистики (например, для on-line оценки наиболее популярных в данный момент запросов), файрвол (автоматически блокирует подозрительные запросы, например, платежные запросы с поддельными или украденными номерами карт). Такому компоненту может потребоваться десериализовать запрос, выполнить свою работу, а затем сериализовать и передать дальше.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
ГВ>>>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять? E>>>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать. ГВ>>А зачем тогда отправлять? Только ради того, чтобы отправить назад? E>Да, в случае с паттерном Async Completion Token
это необходимо.
Нет, не всё так просто. Сервер в общем случае ACT получает бинарные данные, которые и пуляет назад. Что они конкретно обозначают — знает только клиент. А приём/хранение/передача бинарных данных — это совсем не то же самое, что и структурированная [де-]сериализация.
E>Еще один случай, когда нужно сериализовать все обратно, это когда между клиентом и сервером устанавливается еще один компонент, про который ни клиент, ни сервер знать не должны. Такими компонентом может быть маршрутизатор (разные типы запросов на разные сервера), балансировщик нагрузки (выбор наименее загруженного сервера для обработки запроса), сборщик статистики (например, для on-line оценки наиболее популярных в данный момент запросов), файрвол (автоматически блокирует подозрительные запросы, например, платежные запросы с поддельными или украденными номерами карт). Такому компоненту может потребоваться десериализовать запрос, выполнить свою работу, а затем сериализовать и передать дальше.
Тогда одно из двух: либо такому компоненту известно нечто о десериализуемом объекте, либо он выполняет лишнюю десериализацию, поскольку ему может оказаться достаточным передать бинарные данные некоей длины, которая задана во входящем пакете.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, eao197, Вы писали:
ГВ>>>>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять? E>>>>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать. ГВ>>>А зачем тогда отправлять? Только ради того, чтобы отправить назад? E>>Да, в случае с паттерном Async Completion Token
это необходимо.
ГВ>Нет, не всё так просто. Сервер в общем случае ACT получает бинарные данные, которые и пуляет назад. Что они конкретно обозначают — знает только клиент. А приём/хранение/передача бинарных данных — это совсем не то же самое, что и структурированная [де-]сериализация.
Как раз [де-]сериализацию можно научить распознавать известные ей структуры и пропускать (сохраняя по дороге) неизвестные фрагменты.
E>>Еще один случай, когда нужно сериализовать все обратно, это когда между клиентом и сервером устанавливается еще один компонент, про который ни клиент, ни сервер знать не должны. Такими компонентом может быть маршрутизатор (разные типы запросов на разные сервера), балансировщик нагрузки (выбор наименее загруженного сервера для обработки запроса), сборщик статистики (например, для on-line оценки наиболее популярных в данный момент запросов), файрвол (автоматически блокирует подозрительные запросы, например, платежные запросы с поддельными или украденными номерами карт). Такому компоненту может потребоваться десериализовать запрос, выполнить свою работу, а затем сериализовать и передать дальше.
ГВ>Тогда одно из двух: либо такому компоненту известно нечто о десериализуемом объекте,
Естественно что-то знает. Это только для load-balancer-а можно струтуру не знать. Но фишка в том, что промежуточный компонент может не знать всей структуры, а только то, что ему необходимо. И уж тем более ему можно не знать про расширения протокола, которые непосредственно его не касаются.
ГВ> либо он выполняет лишнюю десериализацию, поскольку ему может оказаться достаточным передать бинарные данные некоей длины, которая задана во входящем пакете.
Генадий, у меня складывается впечатление, что много недопонимания здесь возникает из-за того, что как бы неявно подразумевается, что:
— кто-то читает какой-то комуникационный канал (сокет или пайп);
— извлекает очередную порцию данных;
— тут же десериализует ее (т.е. имея исходный двоичный образ);
— после десериализации выполняет обработку и, если нужно, сериализует что-то в двоичный поток и куда-то пересылает.
И все это один и тот же объект.
Но это достаточно низкоуровневый подход. Можно же разбить эти операции на разные уровни:
— первый уровень контролирует канал и извлекает двоичные пакеты;
— следующий уровень проверяет, можно ли выполнить десериализацию и, если можно, десериализует их в прикладные сообщения;
— следующий уровень получае уже прикладное сообщение и обрабатывает его. В результате может быть сгенерированно другое прикладное сообщение;
— исходящее прикладное сообщение второй уровень сериализует в двоичный пакет;
— полученный исходящий двоичный пакет первый уровень пихает в канал.
(в принципе, это более-менее и есть верхние три уровня 7-ми уровневой модели).
Так вот предположим, что есть прикладное сообщение send_message (или make_payment для разнообразия). В нем должен быть идентификатор транзакции. В каком виде этот идентификатор будет присутствовать в send_message (make_payment)? В виде непрозрачного двоичного блока (читай std::string или std::vector<char>)? Но тогда инициатор сообщения должен сделать следующее:
взять свой исходный идентификатор;
сериализовать его в двоичный образ вручную;
поместить двоичный образ транзакции в send_message;
Аналогичные действия, но уже в обратном порядке инициатору сообщения нужно будет выполнить, чтобы десериализовать свой идентификатор из ответного сообщения.
На первый взгляд, это не сложные действия. Но их нужно делать вручную. Хотя можно сделать автоматически, если произвести все идентификаторы транзакций от общего базового класса и применить хитрую автоматическую схему сериализации. Тогда инициатору сообщения нужно будет всего лишь:
поместить исходный идентификатор транзации в send_message.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
* thriving in a production environment *
