![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Записи, макросы, скала, вывод типов, SQL
В очередной раз, в связи с макросами подниму свой любимый вопрос:
Можно ли поиметь в языках типа скалы строгую типизацию, не объявляя типы записей заранее?
Идея в следующем: у меня в Clojure большая часть DSL основана на том, что я могу в любое место описания строк-колонок-ячеек отчета (условно говоря, Excel-like таблица фиксированной формы, заполняемая автоматом из проводок) в любой момент добавить атрибут типа :skip-in-vat true и обработать его. При этом мне нужно это изменить ровно в двух местах - описание документа ("данные") и расчетный алгоритм ("код"). Типов тут нет, а вместо них - структуры данных, скомбинированные из словарей, массивов и атомарных данных.
Но с динамически типизированными языками, а особенно с Clojure с ее destructring и прагматичным подходам к совместимости типов имеется постоянно проблема вида "сунул лишние скобки, на место числа попал массив и через 100500 вызовов когда дело дошло до суммирования, оператор + сдох от попытки просуммировать ссылку на массив со стек-трейсом на три страницы". Причем если мне такие ошибки чинить достаточно легко, то менее опытным коллегам это вырывает мозг.
В F# и прочих типизированных языках же мне придется сначала ползти в описание записи (если там записи вообще есть), добавлять поле или хуже того - еще один вариант для алгебраического типа, править вызовы конструкторов (если оверлоадинга нет) и прочая и прочая.
Кроме того, часто хочется такого: "тип записи создается в SQL запросе и далее используется в функции, обрабатывающей результат запроса". В clojure это опять же - словарь, с кейвордами в качестве ключей.
Языки же кроме F#, Scala и Clojure можно не рассматривать вообще - на них аналогичные задачи или сводятся к "наняли 100 ртишников по одному на объект предметной области и написали вручную" или к "написали самодельный лисп с хаскелем на дельфи/C#" или к "используем безумные ORM с еще более дикими, чем SQL языками и внешними декларативными описаниями".
Т.е. я не говорю, что они не пригодны - но затраты ресусов на решение задачи на таких языках заметно больше.
Можно ли поиметь в языках типа скалы строгую типизацию, не объявляя типы записей заранее?
Идея в следующем: у меня в Clojure большая часть DSL основана на том, что я могу в любое место описания строк-колонок-ячеек отчета (условно говоря, Excel-like таблица фиксированной формы, заполняемая автоматом из проводок) в любой момент добавить атрибут типа :skip-in-vat true и обработать его. При этом мне нужно это изменить ровно в двух местах - описание документа ("данные") и расчетный алгоритм ("код"). Типов тут нет, а вместо них - структуры данных, скомбинированные из словарей, массивов и атомарных данных.
Но с динамически типизированными языками, а особенно с Clojure с ее destructring и прагматичным подходам к совместимости типов имеется постоянно проблема вида "сунул лишние скобки, на место числа попал массив и через 100500 вызовов когда дело дошло до суммирования, оператор + сдох от попытки просуммировать ссылку на массив со стек-трейсом на три страницы". Причем если мне такие ошибки чинить достаточно легко, то менее опытным коллегам это вырывает мозг.
В F# и прочих типизированных языках же мне придется сначала ползти в описание записи (если там записи вообще есть), добавлять поле или хуже того - еще один вариант для алгебраического типа, править вызовы конструкторов (если оверлоадинга нет) и прочая и прочая.
Кроме того, часто хочется такого: "тип записи создается в SQL запросе и далее используется в функции, обрабатывающей результат запроса". В clojure это опять же - словарь, с кейвордами в качестве ключей.
Языки же кроме F#, Scala и Clojure можно не рассматривать вообще - на них аналогичные задачи или сводятся к "наняли 100 ртишников по одному на объект предметной области и написали вручную" или к "написали самодельный лисп с хаскелем на дельфи/C#" или к "используем безумные ORM с еще более дикими, чем SQL языками и внешними декларативными описаниями".
Т.е. я не говорю, что они не пригодны - но затраты ресусов на решение задачи на таких языках заметно больше.
no subject
Впрочем, многим это доставляет удовольствие, так что не хочу больше мешать.
no subject
И чтобы оно все из базы данных приходило без издевательств над здравым смыслом вида "а теперь мы схему базы данных пишем не на SQL а на руби".
Пока единственный вариант - либо генерить код, либо динамическая типизация.
no subject
no subject
Речь о чем:
1) работать с результатами SQL запросов гораздо проще, если их выразить в виде типизированных последовательностей. По крайней мере, C# с LINQ делает именно так. Но у него есть недостаток - полученный в результате селекта тип анонимен и его нельзя вернуть толком за пределы функции.
2) Для того чтобы добится одновременно гибкости в стиле "структуры данных из словарей и массивов" и строгой типизации - действительно нужно генерировать тип, исходя из данных. Формально это возможно, данные доступны при компиляции и конечны, их типы поддаются унификации и в можно проверить валидность полученного результата, просто посмотрев на сгенерированный тип. Как минимум, можно выдать ворнинг, если в одном и том же поле в соседних записях лежат строки, числа и функции :)
no subject
Судя по тому, что вы пишете ниже, я не могу удержаться от ощущения, что вы бы предпочли заняться этим самостоятельно.
работать с результатами SQL запросов гораздо проще, если их выразить в виде типизированных последовательностей
Ну так оно и есть - у вас есть последовательность типов вида DBRecord. Или хочется завести что-то вида rec.username или rec.email? rec.phone? rec.salary? А занафига? А если его там не оказалось? Отняли у пользователя masha права на просмотр юзернеймов - и что делать теперь Маше, ставить отдельный билд, где .username отсуствует? Ну, в принципе, можно и отдельные билды для таких случаев иметь, отчего бы и нет. И даже строить их автоматически... В случае 8 таких самостоятельных полей потребуется всего-то 256 билдов; при 32 полях ситуация будет, конечно, похуже - но можно и завести отдельный пункт в договоре о поддержке.
Формально это возможно, данные доступны при компиляции
Данные при компиляции, увы, недоступны.
no subject
no subject
use-case "отняли у маши права на просмотр полей" это очень хорошая тема. Но требуется уточнение, что вы имеете в виду под этим: административное решение "маша не должна видеть поле username" или техническую реализацию в некоторых СУБД, позволяющих выделять права на select в разрезе отдельных полей таблиц?
В обоих случаях, насколько я понимаю, пользователи с разными правами используют разные запросы к БД, т.к.
в первом случае нужно спрятать username, а во втором одинаковый запрос просто сломается, если в нем будет username и он будет выполнен от имени пользователя у которого нет прав на просмотр этого поля.
Разные запросы - разные модули UI - разные билды - особой разницы нет, на чем комбинаторный взрыв устраивать. Или же генерировать SQL запросы, анализируя права доступа к полям?
no subject
"Вывести список заказов невозможно, так как имя пользователя неизвестно"? Ну пусть...
Но требуется уточнение, что вы имеете в виду под этим: административное решение "маша не должна видеть поле username" или техническую реализацию в некоторых СУБД, позволяющих выделять права на select в разрезе отдельных полей таблиц?
Имеется в виду административное решение путем технической реализации. Ну как я в бытность работы "в одном крупном телекоме" мог видеть номера телефонов, а вот колонка с ФИО владельца мне просто не показывалась - не было такой.
В обоих случаях, насколько я понимаю, пользователи с разными правами используют разные запросы к БД
Нет. В одном случае в select * from msisdn есть колонка с фио, в другом - ее нет.
no subject
Я правда, слышал, что select * from делать не принято, но в этом случае по другому не получится.
Подобная реализация подразумевает специфическую организацию системы. Как минимум, двухзвенку вместо трехзвенки, или вудуизм с протаскиванием аутентификационного токена пользователя от клиента, через сервер приложений до СУБД.
И, насколько я понимаю, этот функционал с запиливанием доступа к полям работает по разному (если вообще присутствует) в разных СУБД?
no subject
1) Типы (схема БД) - тоже данные
2) Компиляцию не обязательно делать у разработчика, она может производится и при старте системы у заказчика. В нормальных языках, я имею в виду.
Формально валидация данных в БД при старте ничем не отличается от проверки валидности типов при компиляции.
no subject
Да, но верить в них можно только в течение одной транзакции.
2) Компиляцию не обязательно делать у разработчика, она может производится и при старте системы у заказчика. В нормальных языках, я имею в виду.
В еще более нормальных они автоматически делаются при каждом изменении схемы :-)
no subject
1) научить макрос лазить в базу при компиляции и генерить по DDL описания типов. Насчет скалы не знаю. в хаскеле TH это в принципе позволяет.
2) использовать ФВП
procData :: (sqlData -> Record) -> sqlData -> result
fetchData :: ( (sqlData -> Record) -> sqlData -> result) -> connection -> result.
В этом случае procData не будет иметь никакого понятия о том, какой тип ей подсунули, и работать с ней можно будет только с помощью переданного словаря. Типизация будет соблюдена. Но лишних слов при этом писать больно уж много. В этом варианте можно придумать много вариаций на тему различной степени извращенности, но крепко не уверен, что оно того стоит.
А чем вам не нравится вариант "описывать структуру базы на руби" ?
no subject
Точнее, лазить в некоторую внешнюю (по отношению к хацкелёвой программе) схему, которая может и обновляться при компиляции.
no subject