Здравствуйте, vdimas, Вы писали:
V>Работает несложно. В С++ принято считать "исполняемым" любой тип с определенным в нем operator() (оператор вызова ф-ии). В общем, это обычный метод со специальным именем, типа как Invoke у делегатов дотнета. V>Простой пример вот: V>
V>Это один из подобных самописных узлов исполняемого AST. Надо проинициализировать "замкнутые" значения v1, v2, а затем рассматривать этот объект как функтор с арностью 1.
Это мне как раз понятно. Непонятно, как будет работать оптимизация. На всякий случай напомню вам, что задачи "вызывать" этот функтор у нас не стоит. Вместо него должна быть выполнена операция index seek по подходящему индексу.
В C# всё как раз гораздо лучше — есть понятие Expression Tree, которое заполняется при построении лямбды, и я могу его потом интроспектировать.
V>Для библиотеки не жалко. Только я бы, по праву автора библиотеки, ограничил бы вдвое, чтобы в середине всегда был мембер.
V>Зависит от отображения типов на хранилище. Если используем какой-нить boost::multiindex, то на нем как раз индексы можно описать через мемберы хранимых элементов (т.е. ключ не дублируется, в отличие от std::map<> или System::Dictionary<>).
Ладно, поверю вам на слово. Хотя есть много подводных камней — т.к. всё, что у нас есть, это указатель на мембер (грубо говоря, какие-то там два поинтера), который нельзя персистить, ведь он может меняться от запуска к запуску. Придётся придумывать специальную процедуру инициализации, которая сможет связать физически хранимый индекс с его ключами, выраженными в виде набора указателей на мемберов.
V>В общем, ничего нового под луной: чем меньше захардкожено в отображениии типов и соотв. хранилища под его экземпляры, тем больше потребуется метаинформации. Обычно метаинформацию о типах С++ организуют как инстансы неких описательных структур, в которых хранятся опять же указатели на мемберы типа.
Ну, понятно. То есть DDL у нас опять же получается довольно-таки ужасным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет.
Брееед! TDOP прост как пробка и ресурсы не ест.
Они просто не знали. Или не хотели замечать то, что не сводится к куче матана.
Более того если бы они показали людям TDOP их с их автоматными парсерами просто послали бы куда подальше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>И много языков умеет сервер рсубд ? WH>Зачем сервер?
mysql, так сгодится ? Много ли он языков умеет ?
I>>когда, куда и как сохранится модель персистентных объектов это дело десятое. Главное что в ней многие вещи делать проще и перформанс искаропки. WH> То-то народ плачет глядя на то как тяжёлые ОРМ тормозят.
Плачет, еще как. Реляционная модель в принципе не предполагает перформанс в тех запросах, которые я указал.
Здравствуйте, Sinclair, Вы писали:
V>>Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит. S>Впервые об этом слышу. Кто вам сказал такую глупость? DSL, по определению, нельзя "сунуть везде". на название топика посмотрите.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Язык.
ANS>Ок. Я просто требование по быстродействию не зря пропустил. Любую технологию можно загнобить сказав "а-а-а. оно не может доработать за х наносекунд", ANS>Я думаю ты спорить не будешь, что написать какой-то "эффект" на Adobe Pixel Blender будет проще, чем его же на C.
Не буду. Проще можно, но будет хуже (по скорости).
>А в конечном итоге оно даже работать может быстрее, просто потому, что во много кода можно напартачить.
Если партачить, то все будет хуже. Надо не партачить, а тогда быстрее не будет. Чудес не бывает. Там нужно выполнить определенный набор команд сколько-то миллионов раз, и чем меньше будет посторонних команд, тем быстрее будет.
ANS>Но в общем спорить никто не будет, что если действительно встанет вопрос оптимизации, то в конечном итоге можно дойти и до низкоуровневого программирования.
Здравствуйте, Ikemefula, Вы писали:
I>>>И много языков умеет сервер рсубд ? WH>>Зачем сервер? I>mysql, так сгодится ? Много ли он языков умеет ?
Ох. Мы и сами язык сделать можем. После чего транслировать его в SQL.
Тоже мне бином Ньютона.
I>Плачет, еще как. Реляционная модель в принципе не предполагает перформанс в тех запросах, которые я указал.
Ничего ты не указал.
А учитывая, что у AVK все лежит в РБД никакого перформанса не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Ширина охвата так себе. Книга хороша именно своей практичностью. Показывает как от теории переходить к практике. А так-то полно других работ из этой же области, с разной глубиной по разным темам (порой многократно глубже).
Ни хрена там практического нет.
VD>>Парсерам же вообще уделяется слишком много внимания в литературе посвященной компиляторам и языкам. Мне кажется это следствием того, что человечество до сих пор не нашло приемлемого решения этой проблемы. А проблема эта возникает самой первой при разработке языка.
V>И не найдет.
Ну, да. Если игнорировать наличие нашей реализации, то можно любые выводы сделать.
V>Чем "естественнее" язык, тем он неоднозначнее и сложнее для автоматического разбора. ИМХО, с ростом мощности компьютера стоит ожидать роста сложности обрабатываемых грамматик.
Что значит "естественнее"? У понятия естественный язык есть четко значение. Русский, Английский и т.п., вот естественные языки. Вот только они не имеют отношения к копьютерным языкам. Там свои проблемы.
Для парсинга же компьютерных языков есть https://github.com/rampelstinskin/ParserGenerator. Ну, и АНТЛР тоже сгодится, если не нужна расширяемость.
VD>>Наука она идет путем перебора всех возможных вариантов (за счет того, что каждый аспирант ищет тему для дисера, которая не пересекается с другими дисерами).
V>Просто сейчас появились возможности для экспериментов, т.к. память больше не ресурс (С). Отсюда все эти эксперименты мемоизацией или распараллеливанием, немыслимые еще 10 лет назад.
Тебе конечно виднее, но вот алгоритм который в итоге получился у Вольфхаунда использует константный объем памяти и обеспечивает при этом весьма высокую производительность.
V>Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет.
Эти вопросы никого больше не интересуют. Я наткнулся даже на такую мысль — в нашей системе почти стирается грань между деревом разбора (Parse Tree) и AST, так как у нас просто нет тех проблем, что присуттвуют в BNF (порождающих грамматиках). За счет богатого синтаксиса/семантики и отсутствия неоднозначностей наше дерево разбора получается практически эквивалентным AST. Разве что скобки мы не уничтожаем. Но они вряд ли сильно помешают преобразованиям. А вот проблем пустых переходов у нас нет, так как нет нужды делать пустые правила обеспечивающие устранение неоднозначностей в грамматиках. Да и самой проблемы переписывать грамматику так, чтобы что-то там обходить у нас нет. Операторы описываются приоритетами, есть циклы и необязательные подправила, и вообще нет пустых подправил.
В общем, в наша реализация полностью устраняет проблему написания парсеров.
Остается приделать такую же высокоуровневвую систему типизации, систему трансформации и получится великолепный мета-язык для описания любых языков программирования (как ЯОН, так и ДСЛ).
Так что остается только одна проблема. Как заставить неверующих Фом хотя бы взглянуть на то, что у нас получается. Я уже не говорю об использовании.
В этом перевернутом с ног на голову мире без бабла и пиара трудно пропихнуть новую идею.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
I>>mysql, так сгодится ? Много ли он языков умеет ? WH>Ох. Мы и сами язык сделать можем. После чего транслировать его в SQL. WH>Тоже мне бином Ньютона.
Значит всё таки SQL ? Ну тогда покажи мне SQL который будет выполнять какой нибудть итерационный алгоритм на графах заодно покажи кусочек DSL который будет генерить это дело.
I>>Плачет, еще как. Реляционная модель в принципе не предполагает перформанс в тех запросах, которые я указал. WH>Ничего ты не указал. WH>А учитывая, что у AVK все лежит в РБД никакого перформанса не будет.
Значит ему нужна простая работа с объектным деревом, а не только перформанс. Меня же интересует в основном перформанс. Что бы было понятно — объектна модель искаропки позволяет выполнить запрос за время меньшее чем самый банальный селект со всеми индексами, кешами и прочей ерундой.
Здравствуйте, Sinclair, Вы писали:
S>Это мне как раз понятно. Непонятно, как будет работать оптимизация. На всякий случай напомню вам, что задачи "вызывать" этот функтор у нас не стоит. Вместо него должна быть выполнена операция index seek по подходящему индексу. S>В C# всё как раз гораздо лучше — есть понятие Expression Tree, которое заполняется при построении лямбды, и я могу его потом интроспектировать.
А каков механизм "интроспекции"? Как обходить будешь на дотнете? Ну т.е. строить самый первый план запросов? В общем, для плюсов доступна т.н. техника "статического визитора", которая не совсем является классическим вихитором, но устойчиво так называют из-за статического ad-hoc полиморфизма:
Тип equal я привел условно, неохота листать исходники boost:lambda для точного имени аналогичного типа, просто показал принцип. Но это мы уже глубоко в детали подались.
V>>Для библиотеки не жалко. Только я бы, по праву автора библиотеки, ограничил бы вдвое, чтобы в середине всегда был мембер. S>
V>>Зависит от отображения типов на хранилище. Если используем какой-нить boost::multiindex, то на нем как раз индексы можно описать через мемберы хранимых элементов (т.е. ключ не дублируется, в отличие от std::map<> или System::Dictionary<>). S>Ладно, поверю вам на слово. Хотя есть много подводных камней — т.к. всё, что у нас есть, это указатель на мембер (грубо говоря, какие-то там два поинтера), который нельзя персистить, ведь он может меняться от запуска к запуску.
Не факт что в задаче персистить от запуска к запуску надо... Я же говорю — уже пошло слишком много деталей на одного меня. Если любопытно, загляни в доку к boost::serialization. Выглядит это так (из примера):
class gps_position
{
friend class boost::serialization::access;
friend std::ostream & operator<<(std::ostream &os, const gps_position &gp);
int degrees;
int minutes;
float seconds;
template<class Archive>
void serialize(Archive & ar, const unsigned int/* file_version */){
ar & BOOST_SERIALIZATION_NVP(degrees)
& BOOST_SERIALIZATION_NVP(minutes)
& BOOST_SERIALIZATION_NVP(seconds);
}
public:
// every serializable class needs a constructor
gps_position(){};
gps_position(int _d, int _m, float _s) :
degrees(_d), minutes(_m), seconds(_s)
{}
};
S>Придётся придумывать специальную процедуру инициализации, которая сможет связать физически хранимый индекс с его ключами, выраженными в виде набора указателей на мемберов.
В любом случае для персиста потребуется арнтайм-метаинформация не только о типах прикладного языка, но и о структуре хранилища и об их взаимном ORM.В каком виде идет эта информация — не принципиально. ORM для C++ можно делать в технике, похожей на технику сериализации (это фактически одно и то же).
V>>В общем, ничего нового под луной: чем меньше захардкожено в отображениии типов и соотв. хранилища под его экземпляры, тем больше потребуется метаинформации. Обычно метаинформацию о типах С++ организуют как инстансы неких описательных структур, в которых хранятся опять же указатели на мемберы типа. S>Ну, понятно. То есть DDL у нас опять же получается довольно-таки ужасным.
Не очень. Компиляторы давно научились "склеивать" идентичный код, порожденный шаблонами для разных типов. Первые компиляторы С++ действительно порождали ОЧЕНЬ МНОГО бинарного кода, уникального для каждого инстанса шаблонной ф-ии или метода.
Здравствуйте, WolfHound, Вы писали:
V>>Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет. WH>Брееед! TDOP прост как пробка и ресурсы не ест.
Это LALR или LL(1) ресурсы не ест.
WH>Они просто не знали. Или не хотели замечать то, что не сводится к куче матана. WH>Более того если бы они показали людям TDOP их с их автоматными парсерами просто послали бы куда подальше.
Дык, Пратт его показал в каком-то махровом 70-м году и никто ни кого не послал. Ведь Дракон — лишь одна из мн-ва работ на эту тему, но почему-то стала более популярной... Не насильно же...
А теоретических работ по детерминированному парсингу недетерминированных грамматик хватало, от Ахо в т.ч. И там же 100 раз говорилось, что у всех этих "приоритетных" грамматик, в отличие от однозначных, трудно вывести св-ва грамматики. И практически невозможно доказать сохранение эквивалентности грамматики во время преобразований (например факторизации), бо упираемся в проблему останова и т.д.
Ну и самое главное, существующие ЯП позволяют решать синтаксические неоднозначности на семантическом уровне, что НАДЕЖНЕЕ, чем это:
Так правило "кто длиннее тот и прав" разрешает чуть менее чем все конфликты.
VD>Так что остается только одна проблема. Как заставить неверующих Фом хотя бы взглянуть на то, что у нас получается. Я уже не говорю об использовании. VD>В этом перевернутом с ног на голову мире без бабла и пиара трудно пропихнуть новую идею.
Влад, ты хоть представляешь, сколько уже было работ на тему детерминированного разбора недетерминированных грамматик? TDOP уже порядка 30-ти лет.
Я уже рядом ответил — всё упирается в св-ва получаемой грамматики. Для приоритетных грамматик вывести их св-ва практически невозможно. Поэтому как практический прием — вполне сойдет, а теоретическое док-во придется еще подождать.
Опять же, надо смотреть чуть шире на происходящее. Алгоритмы типа LL(k), GLR или LALR и так прекрасно подходят зачастую, при том что, никто ничем не рискует (давно уже всё изведано) и скорость парсинга неплохая. Станет некий программный архитектор выбирать "темную лошадку" в кач-ве технологии, если есть извеcтные и доказанно-работающие решения? Ну разве что от зашкаливания авантюризма... Тем более, что в том же в компиляторе С++ парсинг занимает единицы % от всего времени компиляции...
WH>>>Ибо в SQL нет средств декомпозиции кода. V>>И не нужен. Большинство актуальных запросов формируются ТОЛЬКО динамически.... Дык, где тогда должна быть декомпозиция: в SQL или в его генераторе? WH>Осталось понять, почему они формируются динамически.
Требования изменяются динамически.
Но это не важно. Мне интересно, какая проблема рассматривать SQL как язык промежуточного протокола к базе? Тем более, что это так и есть.
WH>Все запросы должны быть проверены на соответствие новой структуре БД. WH>Иначе получишь вылеты в рантайме. Динамическая типизация во всей красе.
Для read-only запросов не страшно.
V>>Плох тот админ, которому требуется монопольный доступ к базе для её модификации. WH>Плох тот админ, который руками в продакшен базу лезет. WH>Обновления в продакшен должны выкатываться только после тестирования.
Они и выкатываются после тестирования. Но это никак не отменяет возможной динамики происходящего.
Я вообще не вижу проблем с декомпозицией построителя запросов. Тем более, что как раз писали генератор SQL и во многих проектах юзали. Очень удобно декомпозировать запросы на прикладном уровне, со стороны O, а не со стороны R в действе, под названием ORM.
V>>Что значит "масштабировать"? Любой ресэмплинг неважно в какую сторону предполагает один из алгоритмов фильтрации. А фильтрация ес-но должна быть сугубо покомпонентной. Кодировки с одинаковыми компонентами отличаются от цветоразностных тем, что оперируют одной и той же частотой сглаживания и цветовой глубиной. Альфа-канал — это тоже независимая компонента, по которой над делать независимую фильтрацию. WH>Теоретик. WH>Вот что получается, если альфу игнорировать. WH> WH>А так если нет. WH>
Ничего не понял... Что значит "игнорировать альфу"? Можно поинтересоваться, какой алгоритм фильтрации при ресэмплинге ты сейчас критикуешь, а какой тебе показался лучше? А то, глядя на пример, я уже начинаю подозревать, что ты пытаешься сравнивать "тупой" ресэмплинг на целочисленных операциях с ресэмплнгом, использующим хоть какую-то фильтрацию.
V>>Есно, достаточно одной лишь зависимости, чтобы транзитивно вывести остальные — это св-во линейности преобразований. Но этого мало, ведь при преобразовании м/у кодировками меняется цветовое разрешение. WH>Смешно. Ибо многие преобразования нелинейные.
Ну, в обработке сигналов нелинейными считаются преобразования, которые не позволяют делать взаимно-обратные преобразования. Например, взятие модуля числа — нелинейное преобразование. А коррекция гаммы в этом плане однозначна в обе стороны.
V>>Ну хорошо, а можно посмотреть отрывок этого DSL? WH>Нельзя. У меня на руках исходников нет. Они все в конторе остались.
Мог бы по памяти привести пару отрывков или условный код? Бо пример твой уж очень специфический. Я хоть и за DSL, но пытаюсь понять, при чем он тут для этой задачи.
ANS>>В твоём примере, в один проход втиснуто много операций /бизнес-логики/. AVK>Непонятно. А чем будет полезно много проходов?
Так я как бы про это написал. Если ты разобъёш эту функцию на несколько кусков, чтобы каждая представляла элементарную-бизнес операцию, то у тебя просядет производительность. В результате, из-за навигационного API у тебя возникает вопрос, что лучше получить читаемый код или производительный.
ANS>>Теперь, бьём эту функцию на элементарные операции — получится десяток запросов. Эти запросы без комментариев будут однозначно понятнее этой лапши с комментариями.
AVK>Пример привести можешь?
var cardsDeleteSet =
SELECT io
FROM InventoryOperation io
INNER JOIN Inventory i
INNER JOIN InventoryInternalDisplacementOperation iido
INNER JOIN InternalDisplacementDocument d
WHERE
d.id IN (:objectsIds)
AND io.kind == InventoryOperationKindEnum.InternalDisplacement
AND io.InventoryCardBefore != io.InventoryCardAfter
AND io.InventoryCardAfter.type != 'AccrualAccountingInventoryCard';
DELETE FROM ...
"inner join" это артефакт, в DSL можно делать проще используя точечную нотацию.
Явно лучше 10 запросов, пусть даже с пересекающимися "WHERE" чем несколько вложенных циклов, которые и удаляют и обновляют и что-то в Set накапливают.
ЗЫ. А как такое авто-тестировать?
ЗЗЫ. почему не начался спор, что лучше Rich или Anemic?
Здравствуйте, vdimas, Вы писали:
WH>>Брееед! TDOP прост как пробка и ресурсы не ест. V>Это LALR или LL(1) ресурсы не ест.
Ты хоть знаешь как TDOP работает
Вот основной цикл. Чему тут тормозить?
var expression = function (rbp) {
var left;
var t = token;
advance();
left = t.nud();
while (rbp < token.lbp) {
t = token;
advance();
left = t.led(left);
}
return left;
}
TDOP линеен.
V>Дык, Пратт его показал в каком-то махровом 70-м году и никто ни кого не послал. Ведь Дракон — лишь одна из мн-ва работ на эту тему, но почему-то стала более популярной... Не насильно же...
Насильно. Ибо в институтах только это направление и дают.
V>А теоретических работ по детерминированному парсингу недетерминированных грамматик хватало, от Ахо в т.ч.
Работ по созданию распознавателей на основе языка для генерации.
БНФ описывает ГЕНРАЦИЮ, а не распознавание.
Тебе не скажется что сама постанвка задачи бредовая?
V>И там же 100 раз говорилось, что у всех этих "приоритетных" грамматик, в отличие от однозначных,
Это БНФ то одназначная?
Вот ПЕГ однозначный. TDOP тоже.
А БНФ неоднозначная. Да еще и не для этой задачи придумана.
V>трудно вывести св-ва грамматики.
Да нахрен эти свойства не упали.
Они нужны теоретикам, ибо без этого работа не будет считать научной.
А практикам они не нужны.
Практикам нужен работающий алгоритм.
V>И практически невозможно доказать сохранение эквивалентности грамматики во время преобразований (например факторизации), бо упираемся в проблему останова и т.д.
Чего?
Нахрена TDOP'у факторизация?
V>Ну и самое главное, существующие ЯП позволяют решать синтаксические неоднозначности на семантическом уровне, что НАДЕЖНЕЕ, чем это: V>
V>Так правило "кто длиннее тот и прав" разрешает чуть менее чем все конфликты.
Тройной фейспалм.
Ты даже не понимаешь, что эту же эвристику используют классические парсеры.
Что? Не знал?
А чем ты думаешь лексер занимается?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Т.е. `source` как параметр передать нельзя. И тут же ты говоришь, что relation это первоклассная сущность. Какой тогда критерий первоклассности чего-либо, если не (не)возможность передать это нечто аргументом в функцию? S>Наличие встроенной поддержки в языке. Критерий передаваемости чего-либо в функцию бессмысленен в отсутствие функций, вы не находите? S>Вот у нас есть relation. Вот у нас есть правила композиции relation, из которых получаются другие relation. Первоклассность этой сущности — в том, что мы внутри запроса можем в любом месте, где нужен relation, подставить любой (подходящий) relation. S>Вы называете это "подзапросами".
А, туплю. Тебя смущает, что нет мета-протокола?
S>>>Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.
мне не совсем понятно, как это использовать. Я беру из пула конекшен, фигашу туда сорок кусков запросов и пятьдесят функций для комбинации этих кусков, потом один запрос который из дёргает эти функции и так при каждом запросе?
Я пока только уверился, что прав в том, что базовый функционал есть весь, что нужно
ANS>> Пожалуй, это проблемы хост-языка, а не самого SQL. S>Пожалуй, вы не понимаете, что такое язык. То, о чём я говорю — это проблемы именно SQL. SQL не предусматривает никакого "хост-языка", а способ, которым вы предлагате "решать это в Java" — ужасен.
Не предусматривает, но практика такова, что есть если не Java, то PL/SQL. Ты конечно, можешь сказать, что процедурные языки имеют все уважающие себя СУБД, но их сделали не для декомпозиции запросов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А, туплю. Тебя смущает, что нет мета-протокола?
Я не понимаю, что такое мета-протокол.
ANS>мне не совсем понятно, как это использовать. Я беру из пула конекшен, фигашу туда сорок кусков запросов и пятьдесят функций для комбинации этих кусков, потом один запрос который из дёргает эти функции и так при каждом запросе?
Нет, зачем? Вы же не создаёте при каждом запросе все view и stored procedures.
Вы берёте, фигачите один раз при развёртывании базы в неё нужные вам функции, которые могут вызывать другие функции, а наружу выставляете только простой и понятный набор таблиц/view/функций/хранимых процедур.
ANS>Не предусматривает, но практика такова, что есть если не Java, то PL/SQL. Ты конечно, можешь сказать, что процедурные языки имеют все уважающие себя СУБД, но их сделали не для декомпозиции запросов.
Процедурные языки, построенные на основе SQL, убоги чуть более чем все. По той же самой причине — есть средства декомпозиции только для императивной функциональности, которая вообще чужда SQL. Лучшее, что могут предложить передовые СУБД — это table-valued функции.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
V>>>Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит. S>>Впервые об этом слышу. Кто вам сказал такую глупость? DSL, по определению, нельзя "сунуть везде". V> на название топика посмотрите.
Посмотрел. Дальше что? Подсказка: "языки общего назначения" и "DSL" — это не синонимы, а антонимы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>>Пример привести можешь?
ANS>[sql] ANS>var cardsDeleteSet = ANS> SELECT io ANS> FROM InventoryOperation io ANS> INNER JOIN Inventory i ANS> INNER JOIN InventoryInternalDisplacementOperation iido ANS> INNER JOIN InternalDisplacementDocument d ANS> WHERE ANS> d.id IN (:objectsIds) ANS> AND io.kind == InventoryOperationKindEnum.InternalDisplacement ANS> AND io.InventoryCardBefore != io.InventoryCardAfter ANS> AND io.InventoryCardAfter.type != 'AccrualAccountingInventoryCard';
Этот кусок на C# короче. И там вполне можно через query comprehension переписать.
ANS>DELETE FROM ...
Ага, а самого то интересного и нет. Как циклы в декларативную форму переделать — догадаться несложно. А вот как последующий алгоритм — вопрос.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>А каков механизм "интроспекции"? Как обходить будешь на дотнете? Ну т.е. строить самый первый план запросов?
Обычным образом — это же данные. Плюс Reflection, т.е. про всех упомянутых мемберов я знаю чуть более чем всё.
Вот подробный рассказ про то, как это делается под капотом: http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-links.aspx
V>В общем, для плюсов доступна т.н. техника "статического визитора", которая не совсем является классическим вихитором, но устойчиво так называют из-за статического ad-hoc полиморфизма: V>
Прикольно. То есть все Expression Trees процессятся статически, во время компиляции?
Как-то мне это кажется подозрительным. В какой-то момент всё равно произойдёт потеря информации о конкретном типе, т.е. рано или поздно всё свернётся в некий Predicate*.
V>Не факт что в задаче персистить от запуска к запуску надо... Я же говорю — уже пошло слишком много деталей на одного меня.
Как правило, неперсистить неинтересно. За один запуск не получается получить так много данных, чтобы запросы по ним имело смысл делать в декларативном виде. (Тут я могу ошибаться, т.к. вроде бы на дотнете народ рапортовал об эффективности индексов в памяти супротив банального сканирования на объёмах от 16 элементов и выше)
Если любопытно, загляни в доку к boost::serialization. Выглядит это так (из примера): V>
V>class gps_position
V>{
V> friend class boost::serialization::access;
V> friend std::ostream & operator<<(std::ostream &os, const gps_position &gp);
V> int degrees;
V> int minutes;
V> float seconds;
V> template<class Archive>
V> void serialize(Archive & ar, const unsigned int/* file_version */){
V> ar & BOOST_SERIALIZATION_NVP(degrees)
V> & BOOST_SERIALIZATION_NVP(minutes)
V> & BOOST_SERIALIZATION_NVP(seconds);
V> }
V>public:
V> // every serializable class needs a constructor
V> gps_position(){};
V> gps_position(int _d, int _m, float _s) :
V> degrees(_d), minutes(_m), seconds(_s)
V> {}
V>};
V>
S>>Придётся придумывать специальную процедуру инициализации, которая сможет связать физически хранимый индекс с его ключами, выраженными в виде набора указателей на мемберов.
V>В любом случае для персиста потребуется арнтайм-метаинформация не только о типах прикладного языка, но и о структуре хранилища и об их взаимном ORM.В каком виде идет эта информация — не принципиально. ORM для C++ можно делать в технике, похожей на технику сериализации (это фактически одно и то же).
Да, при соблюдении определённых правил гигиены всё это может и сработать.
V>Не очень. Компиляторы давно научились "склеивать" идентичный код, порожденный шаблонами для разных типов. Первые компиляторы С++ действительно порождали ОЧЕНЬ МНОГО бинарного кода, уникального для каждого инстанса шаблонной ф-ии или метода.
Да меня количество бинарного кода не очень колышет. SQL Server под свои внутренние структуры отжирает всё равно на порядки больше. Беспокоит в основном количество того кода, который придётся колбасить прикладному программисту. DML у нас изобилует лишними скобками и подчерками (и это мы ещё намеренно завинтили гайки насчёт произвольных выражений, т.к. у нас в качестве аргументов between() могут быть либо мемберы, либо константы).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>Что бы было понятно — объектна модель искаропки позволяет выполнить запрос за время меньшее чем самый банальный селект со всеми индексами, кешами и прочей ерундой.
Зависит от запроса. Где то быстрее и удобнее реляционная модель, где то навигационный доступ. И помимо сырого перформанса есть еще и масштабируемость, так что даже для одного запроса преимущества того или другого способа могут варьироваться в зависимости от абсолютной нагрузки.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
То-то народ плачет глядя на то как тяжёлые ОРМ тормозят.
