Толочь воду в ступе

[swizard]

Пост навеян свежим ПФП. Статья про circumflex, вот этим вот:

// Выбрать все города Швейцарии, вернуть Seq[City]:
SELECT (ci.*) FROM (ci JOIN co) WHERE (co.code LIKE ”ch”)
ORDER_BY (ci.name ASC) listСтоило ли огород городить, если на выходе всё равно получается нечто, что

Comments

[gabriel_pages]

все сломается, когда в базе уже будет пара сотен записей и кто-то зачет поменять структуру, скажем добавить поле.

[metaclass]

Все сломается с треском, когда на эту таблицу будут ссылаться 100 других таблиц, 1000 триггеров и хранимых процедур.

[swizard]

Конечно, но статическая типизация нам тут тем более не поможет :)

Зато при серьезном изменении схемы или декларации объектов бд я могу максимально автоматизировать рефакторинг кода путем изменения макроса (кодогенератора), а не ползать по всему проекту и изменять каждый запрос руками.

[rastafarra]

> Зато при серьезном изменении схемы или декларации объектов бд я могу максимально автоматизировать рефакторинг кода путем изменения макроса (кодогенератора)

что-то я не вижу такого макроса (кодогенератора) для общего случая.

[swizard]

Для какого "общего случая"? Это же DSL, случай всегда будет частный =)

[rastafarra]

общий случай --- это когда уже есть 100500 таблиц, процедут и триггеров и надо отну табличку поменять. а с ней и... ну ты понял.

собсно сам sql для этого и предназначен, ты же предлагаешь обернуть это дело еще и лиспом.

ну давай так:
был адрес строкой, побили это дело на таблицы улиц, городов, регионов и страны. и как тебе тут твой лисп поможет? 100500 записей уже естественно есть, равно как и ссылки на эту таблицу, все надо сохранить. реквестирую пример решения проблемы твоей чудной технологией.

[swizard]

я же говорю -- если все очень сложно, я точно так же, как и ты, буду работать руками :)

давай

ты играешь за статически-типизированный язык с многоэтажной оберткой запросов, а я за свой вариант

Итак, шаг 1: побили адрес, нормализовали таблицы
Ты: компилируешь проект, он компилируется(!) и приложение падает на старте на этапе сверки схемы.
Я: проект не компилируется, идет ругань на сильную неконсистентность таблиц, которую непонятно как автоматически починить.

Шаг 2: поправили декларацию объектов, по необходимости, дописав новые.
Ты: компилируешь проект, он материться на одну тысячу мест в программе, где твои чудо-запросы не соответствуют типам.
Я: правлю макрос, раскрывающий defclass-db.

Шаг 3:
Ты: все еще кипятишь (возишься с запросами)
Я: скомпилировал проект и доволен :)

[rastafarra]

> Я: проект не компилируется, идет ругань на сильную неконсистентность таблиц, которую непонятно как автоматически починить.

сейчас ты все грохаешь и никаких проверок у тебя я не вижу. покажи как это будет выглядеть в коде, это достаточно интересный момент.

> Ты: компилируешь проект, он материться на одну тысячу мест в программе, где твои чудо-запросы не соответствуют типам.
> Я: правлю макрос, раскрывающий defclass-db.

ты нечестно играешь. поля-до добавили, и объектов понаписали, а дальше-то что с ними делать? у тебя были объекты для адреса, они умерли но появились всякое города и страны. вся веселуха будет тут ;)

[swizard]

Слушай, ну я же специально в нескольких местах уточнил, что в посте я привел прототип, который написал за 15 минут. Я сильно больше времени уже угрохал на дискуссию в комментах :)

Смотри внимательно еще раз: у меня есть DSL (defclass-db) и его компилятор в host-язык (defmacro defclass-db ...).

Я волен придумать какой угодно синтаксис в моем DSL и как угодно обработать его в компиляторе.

Лень мне сравнивать схему в базе с декларацией объекта -- я тупо пересоздаю таблицу при обнаружении консистентности. Не лень -- я нахожу diff полей и делаю ALTER TABLE.

Нельзя делать ALTER TABLE -- я выдаю ошибку (что сломает мне компиляцию, как я этого и ожидаю). Хочу запретить автоматический ремонт при изменении какого-то поля -- ввожу спецсинтаксис для него (типа :forbid-alter t) и подправляю компилятор, чтобы он не чинил таблицу при рассинхронизации этих полей.

А у тебя позиция типа: "ага! сказали лесорубы, и пошли пилить лес ручными пилами" :)

[rastafarra]

концепцию я понял, но без реализации (а это самое интересное) это "пшик" ;)

[swizard]

Да что же ты понял, если ты требуешь "реализацию"? =) Я тебе еще раз говорю -- здесь определяется Domain Specific Language. Определи domain: поставь четко ТЗ, опиши какие конкретно таблицы в схеме, как конкретно используются данные из бд и какой потребовался рефакторинг -- и я тебе покажу, как поможет dsl для этой задачи.

[thesz]

Вот тут мы тебя и поймали. ;)

"Это же DSL, случай всегда будет частный" - религия налицо.

[thesz]

>Конечно, но статическая типизация нам тут тем более не поможет

Сразу виден специалист по статическим типизациям. ;)

Если что, то в ядре объектной модели я вполне могу проделать твои действия. Я обдумывал этот вариант, решил не останавливаться, у меня задача другая и приоритеты другие.

[swizard]

Какие действия и в каком ядре? На компиляции на типах или на рантайме уже потом?

Вот твой код:

string name = "b1";
var query = IPRQuery
.From(ClassA.Description) // Создаём выборку.
.Where( a => a.Index < 10) // прореживаем выборку.
.RelatedTo(ClassB.Description) // Создаём ещё одну выборку -
// экземпляров класса ClassB, состоящих
// хоть в каком-то отношении с экземплярами выше.
// Это ограничивает и первую выборку, кстати.
.Where ( b => b.Name == name) // Прореживаем и...
// проецируем:
.Select( (a,b) => new { Name = b.Name, Index = a.Index, A = a});
foreach (var e in query) { // создание запроса и обращение к БД.
Console.WriteLine("Name "+e.Name+", Index "+e.Index+", ClassA object index "+a.Index);
}Вот мы произвели совсем минорное изменение: переименовали "Name" в "Denominazione" а "Index" в "Registro". Чем нам подсобит типизация, помимо того, что заорет на

[thesz]

>А если переименование имело место только в базе

[swizard]

Нет, не сломается :) Это в конкретно этом прототипе я дропаю таблицу, а на деле-то могу сделать ALTER TABLE