Ну еба. Есть OCaml — компилируемый язык. Есть camlp4, который парсер, претти-принтер и еще целая куча недокументированных костылей. Что охуенно — умеет работать с окамловым AST. То есть ты не как лох программный код изменяешь, как с обычным препроцессором, а уже абстрактное синтаксическое дерево дергаешь. На этой хуйне, значит, пытаются делать всякие расширения. Вот PGOcaml — одно из них. Суть такова: при компиляции ты пихаешь в env координаты postgresql-сервера, и он ходит и смотрит в базе данных, правильно ли ты запросы написал. Если ты вызываешь не те колонки, или с типами проебался — ошибка в компайл-тайме. Очень полезно при рефакторинге и при миграциях, например. В PGOcaml есть, правда, один ебанизм, из-за которого его использовать чрезвычайно хуево: он выдает кортежи. А мне пропатчить некогда. Макака вроде выдает объекты, но я в нее не тыкал.
да. sqlalchemy вообще умеет команду "построй мне модели из БД по такому-то адресу". думаю, дальше тебе фантазии хватит, как сравнить эти модели с моделями в файликах.
ну, я тебе ответил на вопрос, что делаю я. Я описываю модели, а по ним генерируется схема и объекты бизнес-логики всякие, и привязываются друг к другу. Но если бы я не хотел использовать ORM, то описывал бы схему как-то так http://docs.sqlalchemy.org/en/rel_0_8/co... (user = Table...) явно, и по ней можно делать интроспекцию и проверять правильность колонок и так далее за нехуй шо.
блять. Еще раз. SQLAlchemy состоит из двух частей: SQL Toolkit, способного без ORM всякого работать. В него входят описание и интроспекция схемы, построение схемы из реальной БД, очень гибкое собирание SQL-запросов и так далее (без строк и прочего говна). И есть слой ORM, который связывает описание схемы с обыкновенными питоньими объектами.
Явно задаваемая в коде схема — это половина ORM’а. Объясни теперь, с какого перепугу я должен дублировать схему еще и в коде, либо — упаси Боже — генерировать ее из петонового описания.
это вообще к ORMу не имеет никакого отношения. Ты можешь эту схему сгенерировать на лету, да, и SQLAlchemy умеет это делать.
Почему считаю описание схемы в коде более хорошей вещью опишу позже. Заодно пока попредставляю, как вообще возможно подобным образом (хранить и лелеять "канонические БД, из которых схема читается", да еще и для каждой ветви разработки?) так можно работать.
> Ты можешь эту схему сгенерировать на лету, да, и SQLAlchemy умеет это делать. > сгенерировать схему, взяв ее из базы данных > проверить базу на соответствие с этой схемой
то, о чем я тебе говорю как раз о сравнении ручного описания. А фраза "ты можешь сгенерировать базу на лету" — попытка объяснить тебе тупому, что SQL Toolkit не требует описания схемы, и можно таким же извращенным образом как ты работать (хотя я до сих пор не понимаю нахуя).
я не понимаю как это может быть удобно. У тебя ведь наличие БД с актуальной схемой (для каждой ветки) будет стаёт требованием. Ты БД с правильной схемой тоже в репозиторий кладёшь, или что? Или у тебя есть канонический дамп в секретной директории? (и при разработке в ветке с другой схемой ни дай бог потерять).
В общем, мне сложно представить как это может быть удобным (кроме случаев "быстренько написать относительно БД, в которой непонятно что толком"). Тут да, считал из БД её схему и поехал.
Ну и не понимаю претензии "дублировать". Если ты пишешь и правишь код только в одном месте, а уже из него происходят другие вещи (не ограничивающиеся генерацией схемы) — что в этом плохого? Ты же руками в двух местах схему не правишь.
При том, что пейтончеги с рубями исполняются построчно. Ни AST, ни хуя не строится. Разве что классы кешируются. В общем случае нет возможности узнать, что за запросы пойдут в БД.
ебать ты ебанутый. я тебе секрет открою: в общем случае нет возможности узнать, что за запросы пойдут в бд в любом тьюринг-полном языке. я вижу что у тебя какой-то фетиш на аст, наверное потому что ссаном оверблде нихуя нет других средств метапогромированния. петушить аст — вообще довольно хуёвая затея в большинстве случаев просто потому что слишком дохуя сложно, если у тебя не лисп. ну и конечно же ничего не мешает петушить аст в интерпретируемых языках
> я тебе секрет открою: в общем случае нет возможности узнать, что за запросы пойдут в бд в любом тьюринг-полном языке. В рамках использования под честное слово только специальных костылей для петушения SQL’а — можно в случае верблюдов и невозможно в случае петонорубёв. > ссаном оверблде нихуя нет других средств метапогромированния Да. > ну и конечно же ничего не мешает петушить аст в интерпретируемых языках Мешает.
Расскажи, какими средствами петушона можно узнать на этапе инициализации, что какой-нибудь SQL’овый костыль будет вызываться и просить ложные колонки, вроде db.select('hui', pizda').from('djigurda')
не знаю, но знаю что у тебя — ложное ощущение жопной целостности любое твое определение корректности имеет кучу шансов обосраться но твоя sick obscession with practice of defencive programming through static compilation даёт тебе уютную иллюзию не говоря уже о том что для неё сущётсвует куча альтернатив классических динамических языках
51 comment
recommend
bookmark
subscribe
лол
чо лол?
норм ава
спасяб)
Ну еба.
Есть OCaml — компилируемый язык.
Есть camlp4, который парсер, претти-принтер и еще целая куча недокументированных костылей. Что охуенно — умеет работать с окамловым AST. То есть ты не как лох программный код изменяешь, как с обычным препроцессором, а уже абстрактное синтаксическое дерево дергаешь.
На этой хуйне, значит, пытаются делать всякие расширения. Вот PGOcaml — одно из них.
Суть такова: при компиляции ты пихаешь в env координаты postgresql-сервера, и он ходит и смотрит в базе данных, правильно ли ты запросы написал. Если ты вызываешь не те колонки, или с типами проебался — ошибка в компайл-тайме.
Очень полезно при рефакторинге и при миграциях, например.
В PGOcaml есть, правда, один ебанизм, из-за которого его использовать чрезвычайно хуево: он выдает кортежи. А мне пропатчить некогда. Макака вроде выдает объекты, но я в нее не тыкал.
короч, хуйня какая-то, в пхп таких проблем нет
В PHP все валится в рантайме и только тогда, когда ты наскочишь на нужный код, да. Эта поебень как раз призвана от такого спасать.
в рантайме, но подобные ошибки при инициализации можно проверить за нехуй. Ну а доступ к несуществующим аттрибутам линтеры давно умеют.
Но более сложные штуки вроде неправильного GROUP BY — это мощь.
> подобные ошибки при инициализации можно проверить за нехуй
orly?
у меня валится только в процессе девелопмента, что не так?
да. sqlalchemy вообще умеет команду "построй мне модели из БД по такому-то адресу". думаю, дальше тебе фантазии хватит, как сравнить эти модели с моделями в файликах.
Блять, ты схему БД еще и в коде дублируешь?
ну и, собственно, возможны более человеческие решения, просто я подобной целью не задавался.
я описываю модели, да. Что в этом плохого?
Я считаю, что в интерпретируемых языках они сильно слабо возможны.
Модели или схему?
модели, из которых в том числе схема генерируется.
Можно тебя спросить: какое отношение твой ORM имеет к SQL’у?
> SQLAlchemy is the Python SQL toolkit and Object Relational Mapper
Е-е-ебаный в рот.
ну, я тебе ответил на вопрос, что делаю я. Я описываю модели, а по ним генерируется схема и объекты бизнес-логики всякие, и привязываются друг к другу. Но если бы я не хотел использовать ORM, то описывал бы схему как-то так http://docs.sqlalchemy.org/en/rel_0_8/co... (user = Table...) явно, и по ней можно делать интроспекцию и проверять правильность колонок и так далее за нехуй шо.
Бля-я-ять.
Что не так, собственно?
объекты — это сложно!
объекты тормозят!
Меня интересует, какого мы говорим об ORM’е.
блять. Еще раз. SQLAlchemy состоит из двух частей: SQL Toolkit, способного без ORM всякого работать. В него входят описание и интроспекция схемы, построение схемы из реальной БД, очень гибкое собирание SQL-запросов и так далее (без строк и прочего говна). И есть слой ORM, который связывает описание схемы с обыкновенными питоньими объектами.
Короче ты тупой, там же всё написано.
Python SQL toolkit *and* Object Relational Mapper. По отдельности, понимаешь?
даже на главной странице для тупых сделали две большие половины, в одной для ORM, в другой для SQL Toolkit.
Явно задаваемая в коде схема — это половина ORM’а.
Объясни теперь, с какого перепугу я должен дублировать схему еще и в коде, либо — упаси Боже — генерировать ее из петонового описания.
это вообще к ORMу не имеет никакого отношения. Ты можешь эту схему сгенерировать на лету, да, и SQLAlchemy умеет это делать.
Почему считаю описание схемы в коде более хорошей вещью опишу позже. Заодно пока попредставляю, как вообще возможно подобным образом (хранить и лелеять "канонические БД, из которых схема читается", да еще и для каждой ветви разработки?) так можно работать.
> Ты можешь эту схему сгенерировать на лету, да, и SQLAlchemy умеет это делать.
> сгенерировать схему, взяв ее из базы данных
> проверить базу на соответствие с этой схемой
то, о чем я тебе говорю как раз о сравнении ручного описания. А фраза "ты можешь сгенерировать базу на лету" — попытка объяснить тебе тупому, что SQL Toolkit не требует описания схемы, и можно таким же извращенным образом как ты работать (хотя я до сих пор не понимаю нахуя).
> то, о чем я тебе говорю как раз о сравнении ручного описания.
Бля-я-ять.
о сравнении описания схемы БД в коде с состоянием самой БД для проверки соответствия полей и прочей хуйни. Что тебе, блять, снова неясно?
Чувак, весь смысл пгокамла и макаки в том, что не надо дублировать схему на стороне приложения.
я не понимаю как это может быть удобно. У тебя ведь наличие БД с актуальной схемой (для каждой ветки) будет стаёт требованием. Ты БД с правильной схемой тоже в репозиторий кладёшь, или что? Или у тебя есть канонический дамп в секретной директории? (и при разработке в ветке с другой схемой ни дай бог потерять).
В общем, мне сложно представить как это может быть удобным (кроме случаев "быстренько написать относительно БД, в которой непонятно что толком"). Тут да, считал из БД её схему и поехал.
Ну и не понимаю претензии "дублировать". Если ты пишешь и правишь код только в одном месте, а уже из него происходят другие вещи (не ограничивающиеся генерацией схемы) — что в этом плохого? Ты же руками в двух местах схему не правишь.
// будет стаёт — норм
не используешь кресты или лишп
>конпелируется или нет в зависимости от от того что лежит пэже
охуенная задумка, чо
хуйню сказал, при чём здесь интерпретация вообще?
При том, что пейтончеги с рубями исполняются построчно.
Ни AST, ни хуя не строится. Разве что классы кешируются.
В общем случае нет возможности узнать, что за запросы пойдут в БД.
Собственно, вопрос #tishen был как раз на тему «а возможно ли по-человечески в интерпретируемом языке».
ебать ты ебанутый.
я тебе секрет открою: в общем случае нет возможности узнать, что за запросы пойдут в бд в любом тьюринг-полном языке.
я вижу что у тебя какой-то фетиш на аст, наверное потому что ссаном оверблде нихуя нет других средств метапогромированния. петушить аст — вообще довольно хуёвая затея в большинстве случаев просто потому что слишком дохуя сложно, если у тебя не лисп. ну и конечно же ничего не мешает петушить аст в интерпретируемых языках
> я тебе секрет открою: в общем случае нет возможности узнать, что за запросы пойдут в бд в любом тьюринг-полном языке.
В рамках использования под честное слово только специальных костылей для петушения SQL’а — можно в случае верблюдов и невозможно в случае петонорубёв.
> ссаном оверблде нихуя нет других средств метапогромированния
Да.
> ну и конечно же ничего не мешает петушить аст в интерпретируемых языках
Мешает.
Расскажи, какими средствами петушона можно узнать на этапе инициализации, что какой-нибудь SQL’овый костыль будет вызываться и просить ложные колонки, вроде db.select('hui', pizda').from('djigurda')
против такой постановки задачи ни один яп не устоит
с чего ты взял что колонки — ложные?
Еб твою мать. Мне проверить нужно, что все мои запросы — корректны. Желательно ДО того, как на них спотыкнется юзверь в продакшне. Как это сделать?
не знаю, но знаю что у тебя — ложное ощущение жопной целостности
любое твое определение корректности имеет кучу шансов обосраться
но твоя sick obscession with practice of defencive programming through static compilation даёт тебе уютную иллюзию
не говоря уже о том что для неё сущётсвует куча альтернатив классических динамических языках
С таким уровнем дискуссии мне хочется тупо послать тебя нахуй. Объяснить, почему?
лучше просто пошли
Я у плиты стою и занят, поэтому да, сходи нахуй.
во-во, лучше борши вари
гормошки ещё начни упарывать, может что годное получится, я тебя в жены возьму тогда