Comments 25
Всё бы хорошо, но с базами у них всё также уныло. Какая-то странная проблема хаскель-мира.
В Хаскеле есть биндинги для большинства СУБД, но вместе с Happstack предпочтительнее использовать Acid-State — технологию, которая позволяет хранить данные произвольного типа и составлять запросы прямо на Хаскеле.
По ссылке 500 — Internal Server Error
Молчу, молчу…
Молчу, молчу…
Хах, действительно. Еще вчера все было отлично, неужто Хабр завалил?
Можно еще здесь про Acid-State почитать.
Persistent в Yesod очень даже хорошо выглядит, прямо поразительно красивее ООП-ORM'ов в некоторых местах. AcidState выглядит тоже неплохо.
А вы им пользовались? Я вот пытался — это мрак и ад, к сожалению. AcidState в этом плане гораздо симпатичней. Но хотелось бы большего :)
Нет, как раз только сейчас балуюсь ими, потому и интересно узнать подробностей, что вам не понравилось конкретно.
Как только выходишь за пределы простых select-ов, начинается пляска и вырвиглазные конструкции, пропадает красота и лаконичность. Можно взять esqueletto, но там тоже довольно быстро начинаются проблемы. Собственно, некоторые проблемы персистеда описаны в мотивировке к esquletto blog.felipe.lessa.nom.br/?p=68
А, ну тогда ясно. Да, мне как-то в последние годы удавалось все проблемы выражать в упрощенных моделях, без необходимости городить джойны или какой-то сложный SQL.
Esqueletto не трогал, за ссылку спасибо, гляну.
Esqueletto не трогал, за ссылку спасибо, гляну.
> However, what if you didn’t know John’s key, just its e-mail (assuming that there is an uniqueness constraint on e-mails)? Unfortunately, with persistent you’ll need either two queries:
> Or you could do it in one query using the ad hoc Database.Persist.Query.Join.Sql module:
А, теперь понял о чем вы. Да, кошмар/
> Or you could do it in one query using the ad hoc Database.Persist.Query.Join.Sql module:
А, теперь понял о чем вы. Да, кошмар/
Хотя, если честно, я так и не понял, чем автора не устроил
в этом примере с выборкой по имейлу.
maybeMichael <- selectFirst [PersonEmail ==. "michael@haskell.org"] []
case maybeMichael of
Nothing -> liftIO $ putStrLn $ "Sorry, noone found."
Just michael -> liftIO $ print michael
в этом примере с выборкой по имейлу.
Очень хорошим вариантом мне представляется аналог вот такого (https://github.com/jonifreeman/sqltyped). Но ничего подобного для хаскеля я пока не видел.
Ну, sqltyped на первый взгляд — это несколько совсем другое. В смысле, Persistent и AcidState стараются наоборот, абстрагироваться от SQL'а (а AcidState еще и от персистентности и прочего, можно использовать чистые IxSet всякие).
Непонятно зачем городить DSL вокруг DSL-я, который изначально предназначен для работы с SQL? :) А так мы убиваем двух зайцев сразу — не скрещиваем ежа и носорога и получаем (более-менее) type safety.
Не очень понял. Суть «отгораживания от SQL» состоит в том, чтоб база данных (вообще персистентность объектов) была лишь деталью реализации, а не цертром вашей архитектуры. Ваши «бизнес-объекты» — обычные данные, а персистентность прикручивается незаметно в сторонке.
То есть, ORM как раз тем и занимается (в ООП-языках), что мапит ваши бизнес-объекты с описанием табличек, и «в идеале» вы БД можете прикручивать в последний момент. Robert Martin, в общем, уже сто раз рассказал лучше меня об этом.
То есть, ORM как раз тем и занимается (в ООП-языках), что мапит ваши бизнес-объекты с описанием табличек, и «в идеале» вы БД можете прикручивать в последний момент. Robert Martin, в общем, уже сто раз рассказал лучше меня об этом.
Мартин не истина в последней инстанции. Во-первых, SQL стандартный тоже вполне может скрывать детали реализации (какая там конкретная реализация не столь важно, коль скоро мы не пишем в самом SQL ничего спеицифичного), а констрейн на СУБД в любом случае есть. Во-вторых, как только захочется использовать СУБД-специфичные вещи, то детали уже надо будет учитывать. Так что это вопрос подхода. В общем и целом, я считаю, что сам по себе SQL уже хороший уровень абстракции (для веба).
Ну, имеется в виду не то, чтоб «скрывать детали реализации», а в том, что представление бизнес-моделей в хаскеле (тут, наверное, всякие алгебраические типы данных приходят на ум), или же в ООП-языках (обычно модели друг друга биндят прямо в виде моделей, а не через идентификаторы), мягко говоря «иногда» отличаются от того, что хранится в БД. В БД хранятся структуры данных, оптимизированные под представление, удобное для БД. Но оперировать же лучше данными (моделями), представленными в удобном виде для программиста.
То есть, я к тому, что считаю, что нужно иметь как один, так и другой механизм. Отдельно ORM, связывающий данные с персистентностью, и отдельно язык запросов, который позволяет оперировать SQLем в виде, более приятным, нежели строки.
По поводу «СУБД-специфичных вещей» — ну, собственно, суть не в том, чтоб никогда не писать голый SQL, а в том, чтоб трогать его только через некоторый абстрактный интерфейс, который скрывает детали БД и запросов, возвращая уже сами бизнес-объекты.
В общем, не хотелось бы уходить в политику. Предлагаю просто рассматривать два отдельных инструмента: ORM и SQL-абстрагирование и их качество. Их нужность обсуждать уже не хотелось бы :)
То есть, я к тому, что считаю, что нужно иметь как один, так и другой механизм. Отдельно ORM, связывающий данные с персистентностью, и отдельно язык запросов, который позволяет оперировать SQLем в виде, более приятным, нежели строки.
По поводу «СУБД-специфичных вещей» — ну, собственно, суть не в том, чтоб никогда не писать голый SQL, а в том, чтоб трогать его только через некоторый абстрактный интерфейс, который скрывает детали БД и запросов, возвращая уже сами бизнес-объекты.
В общем, не хотелось бы уходить в политику. Предлагаю просто рассматривать два отдельных инструмента: ORM и SQL-абстрагирование и их качество. Их нужность обсуждать уже не хотелось бы :)
Ну я тоже не спорю, что иметь естественный для языка (и как можно более незаметный) «морфизм» из его способа описания данных и связей между ними и хранилищем — отличная штука. :)
я был бы сильно рад увидеть нечто подобное myBatis для хаскеля, потому как все эти умные стрелки очень клево смотрятся в статьях по матану, но в реальности запросы бывают весьма стремными и очень vendor-specific, так что абстрагирование их в каком-нибудь подключаемом текстовом файле и call-by-name было бы попросту отлично. Все попытки сделать ORM упрутся в Hibernate, оно вам надо?
Если честно, не очень понятно, зачем SQL-запросы выносить в XML-файлы, в смысле, почему не построить красивое описание запросов прямо средствами языка (в Х-ле они позволяют это сделать). По поводу упирания в Hibernate не понимаю, почему вдруг, и при чем он здесь.
Потому что красивое описание запросов средствами языка, отличного от SQL принятого для конкретно этой базы данных, вряд ли получится. Таких примеров нет в жабомире, а уж они-то долго старались.
По поводу упирания в хибернейт — вот они как раз пытались сделать красивое описание.
По поводу упирания в хибернейт — вот они как раз пытались сделать красивое описание.
Ну, мне известно как минимум одна библиотека для питона — SQLAlchemy, и это в питоне, который тоже особо своей DSL'ностью никогда не выделялся. В хаскеле синтаксис и семантика позволит сделать еще приятнее.
Ну а то, что у джавы получаются монстры — наверное это проблема джавы. Вон, например, на хаскеле вполне неплохо выглядят parser combinator'ы (parsec, например). То есть даже парсеры (!) можно относительно красиво выражать средствами языка (такого я действительно нигде больше не видел).
Ну а то, что у джавы получаются монстры — наверное это проблема джавы. Вон, например, на хаскеле вполне неплохо выглядят parser combinator'ы (parsec, например). То есть даже парсеры (!) можно относительно красиво выражать средствами языка (такого я действительно нигде больше не видел).
Ну и по поводу «персистентность прикручивается незаметно в сторонке» — это выглядит хорошо на бумаге, а в реальной жизни я не видел ни разу, чтобы об эту незаметность не спотыкались сплошь и рядом.
Не знаю кто как, но я как раз благодаря тому, что все «доставания данных» делал через отдельный интерфейс, смог на реальном проекте вынести кусок функционала в другую БД вполне просто. Бизнес-логика не была затронута совершенно, пришлось менять только интфейс выборки, что сильно облегчило задачу.
В то время, как «меняем БД на монго, пацаны!» встречается не часто, вынос отдельного куска по типу статистики или «больших ненужных данных» — вполне задача сегодняшнего дня.
В то время, как «меняем БД на монго, пацаны!» встречается не часто, вынос отдельного куска по типу статистики или «больших ненужных данных» — вполне задача сегодняшнего дня.
Sign up to leave a comment.
Happstack Lite: Веб-фреймворк на Хаскеле