На лиспе такое элементарно делается. Описать грамматику DSL, сгенерировать парсер, трансформировать AST, сериализовать. За пару часов сделать можно. А если взять парсер от Postgres95 (он же ведь на лиспе написан), то и за час.

ados, alienclaster, antares0, archimag, basp, Begemoth, bioreactor, buddhist, dave, den73, deterok, dmitry_vk, encyrtid, feofan, gensym, lovesan, monk, mv, no-such-file, pseudo-cat, quasimoto, shamaz, staseg, ugoday, unlog1c, yoghurt, yyk, Zubok, анонимный борщевик, — ведь правда же?

А загнать всё в базу уже не такой плохой вариант, по сравнению с вышеизложенным) Вполне быстро(десяток запросов и дамп) и безопасно, если запускать от непривилегированного пользователя и/или в chroot

если скрипты тривиальные то пойдет и эмулятор базы данных - hsql

А СКЛитор не пойдёт?

А если взять парсер от Postgres95 (он же ведь на лиспе написан), то и за час.

файлы с грамматиками есть в самом PG, бери сколько влезет. Только не в этом проблема, не напишешь ничего за час.

а зачем?

Только не в этом проблема, не напишешь ничего за час.

Почему? Ведь лисп намного мощнее всех существующих языков, а лисп-программист на порядки производительнее программистов на С, C++, Java и прочих «мейнстримных» языках.

bioreactor

Он же вроде нормальный был, не?

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

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

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

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

За пару часов сделать можно.

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

яви миру чудо, тем более за пару-то часов... сколько это будет стоит, баксов 30? ;)

Да блин. Мне ничего считать не надо, обкатывать или ещё что. Я просто хочу собрать красивый результат, в котором обновления X и Y смерджены в основной код, а обновление Z осталось вынесенным.

ну вот нет таких средств. и даже если у тебя будет 2 базы, все равно нет средства получить нормальный diff, мудота одна. и приходиться тащить всю историю разработки.

Посмотри LiquiBase, не оно?

Зато diff сразу все говорит

На первый взгляд похоже. Надо будет попробовать.
Интересно только, почему жаба?

Охереть, это на ЛОРе развелось столько лиспачей-сектантов? Development скатывается в тартарары. Скоро профессионалов не останется, одни упоротые борщееды-маргинальщики. Не понимаю, о каком «русскоязычном StackOverflow» может вообще идти речь.

И, что самое интересное, все как один слились! На такой-то элементарной задачке!

Интересно только, почему жаба?

Потому что изо всех современных языков Java лучше всего приспособлена для работы с СУБД. Тут и JDBC с огромным количеством драйверов, и высокоуровневость, и мощное ООП, и статическая типизация, и (в меру) динамичность за счет reflection и introspection, и хорошая производительность благодаря JIT, и кроссплатформенность, и кодогенерация на лету, и прочая, прочая, прочая.

Друг анонимус, ты меня тролешь?

приспособлена для работы с СУБД

мощное ООП, и статическая типизация
reflection и introspection
кодогенерация на лету

Прошу прощения, но что не так?

LiquiBase — комплексная система, которая оперирует данными и метаданными, реализует сложные алгоритмы и поддерживает множество СУБД с их тонкостями. Разумеется, здесь нужен современный и мощный язык программирования. Неудивительно, что ни на сях, ни на лиспохаскелях ничего подобного не напейсали.

Кстати, как успехи? Попробовал уже?

Ты хочешь интерпретатор SQL - таких нет. Можно попробовать sqlite.

P.S. Лиспохейтеры реально достали.

А просветители, популяризаторы науки, разоблачители фоменок и петриков не достали, не? Странно.

Задача сплющить всё это безобразие. То есть вместо десятка alter table создать один результирующий create table, и так далее.

Т.е. ты гарантируешь, что всегда сначала будет идти create table, а потом эту (и только эту) таблицу alter'ят? Или нет?

А вообще ты этого не хочешь, правда. Ибо в общем случае задача не имеет решения (либо имеет весьма и весьма нетривиальное). Тебе выше уже посоветовали правильное решение - юзай liquibase для миграций. Заодно отпадет проблема «а что уже накатили, а что еще нужно накатить?».

на сервере сборки надо держать целый постгрес специально для этой одной цели

Кстати, почему именно на сервере сборки и именно выделенный PostgreSQL? Можно же юзать PostgreSQL с тестового/отладочного сервера, сделав в нем специальную базу/схему. Но тогда, конечно, бильд будет зависеть от доступности сервера PostgreSQL.

ты гарантируешь, что всегда сначала будет идти create table, а потом эту (и только эту) таблицу alter'ят?

На 95% гарантирую. Если только один из разработчиков не решит устроить всем весёлую жизнь, переписав генерацию схемы задом наперёд справа налево.

современный и мощный язык программирования

Ты точно меня тролешь. Всерьёз люди не разговаривают рекламными лозунгами.
Нет, не пробовал. Наверное только в праздники займусь.

Кстати, белко правильно порекомендовало HSQLDB — ведь оно умеет in-memory tables. Т.е. это будет сверхбыстрый интертрепатор SQL. Глагне штобы фсе данные влезли в память. И да, плясать только в рамках стандартного SQL.

только в рамках стандартного SQL

Это какого-такого стандартного? То есть если у меня тип будет называться VARCHAR2, или скажем serial, оно не съест? Ну и зачем оно нужно такое?

Всерьёз люди не разговаривают рекламными лозунгами.

Говнокурсы по Java и Delphi в Мухосрансках уже давно безнадежно устарели, но продолжают по-прежнему пользоваться популярностью. Он с радостью расскажет тебе про bleeding edge технологии: UML, XML и AJAX.

VARCHAR2 — изначально ораклиная приблуда, SERIAL — поцгресовская. Вряд ли HSQLDB из умеет искаропки (но посмотреть не помешает). Так что тут либо настоящий PostgreSQL, либо LiquiBase.

Либо ждать лисперов, лол.

О! А вот и первый борщевик пожаловал!

Ну, что, языком-то ты молоть горазд. А помочь ТСу сможешь? Задачка-то для лиспа элементарная ведь.

Ксилос, эта хрень называется программирование, управляемое данными. На лиспе это очень просто, но ты сука, должен сформулировать формальный инвариант, который обеспечивает проверку входных данных и на выходе правильную семантику create table с нужными полями.

должен сформулировать формальный инвариант

А еще трансформировать метациркулярный трансформер, ага.

На лиспе это очень просто

На словах ты Лев Толстой, а на деле хуй простой.

Задачка нихрена не элементарная, ты мне тут не пизди, школьница неподмытая, озабоченная борщом. Может оказаться, что она формулируется некорректно в плане математики, можно ли из ограниченного набора в множестве sql операций и входных данных, корректно сформировать единственный оператор create table с нужными полями?

На словах ты Лев Толстой, а на деле хуй простой.

При всем моем уважении, мне кажется, что при подобном уровне аргументации, я не смогу продолжать полемику, в силу своих культурных и эстетических принципов. Прошу прощения. Да хранит вас Господь. Спасибо и извините, что потратил ваше время.

На словах ты Лев Толстой, а на деле хуй простой.

Сразу видно — франкфуртский джазмен!

Рязань-стайл же, чо.

Может оказаться, что она формулируется некорректно в плане математики кококококо кукареку

А вот PostgreSQL эту задачу решает. Аффтары математику не учили, видимо, не знают лямбда-калькулюса и теорката, а посему не могут в анафорическую лямбду и пандорический захват.

Только у них почему-то все работает. В отличие от лиспа.

Сразу видно — франкфуртский джазмен!

Завидуй молча, бездарь и ничтожество.

А вот PostgreSQL эту задачу ряешяает.

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

Но, Ксилокса в его ПТУ в городе Кирове, таким вещам не учили, а сейчас он хочет чудес, семантику SQL специализировать на Lisp DSL забесплатно, блядь.

Я не понимаю, почему у борщевиков так люто, бешено бомбит от вполне обычных явлений?

Ну играет чувак на саксофоне в клубах, что такого? Талант есть, заработал денег, купил инструмент, пошел заниматься, освоил, выступает.
Ну, кому-то не нравится жить в городах, заработал денег, купил дом в сельской местности, переехал, что такого? На девушку-тайку бугуртят — так тут интернациональные браки вообще на каждом шагу.

Для Европы это все в норме вещей, я просто не понимаю причин термоядерного бугурта и массового разрыва пердаков.

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

Завидуй молча, бездарь и ничтожество.

С удовольствием позавидовал бы умному и компетентному специалисту. Но у нищебродствующих быдлокодеров на аутсорсе завидовать нечему. Разве что богатой фантазии.

Я уверен, что такие решения должны быть.

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

Анонимус доставляет, спасибо, давно так не ржал.

Никаких домиков у озера нет! И спутники не летают, это все выдумки! И глубоководные аппараты не погружаются! И таек не существует!! И ракеты никуда не летают, и самолеты не перевозят грузы и пассажиров, это все выдумки, а существует только Б-жественный ЛNСП!..

(Тут лиспер очнулся. На столе стояла недоеденная тарелка борща. Борщ давно остыл и подернулся мутной пленкой жира...)

Это всё есть, но шпана, вроде тебя, к этому не имеет никакого отношения.

А просветители, популяризаторы науки, разоблачители фоменок и петриков

Здесь нет популяризаторов и разоблачителей. Есть пара лунатиков, которые постоянно попрекают воображаемых лисперов поеданием мамкиного борща. Постоянно, блеать.