int_index Jul 4 2013 at 17:05

Happstack Lite: Веб-фреймворк на Хаскеле

9 min

13K

Website development*Haskell*

Tutorial

Recovery Mode

Translation

+26

Comments 25

zw0rk Jul 4 2013 at 18:30

Всё бы хорошо, но с базами у них всё также уныло. Какая-то странная проблема хаскель-мира.

int_index Jul 4 2013 at 18:56

В Хаскеле есть биндинги для большинства СУБД, но вместе с Happstack предпочтительнее использовать Acid-State — технологию, которая позволяет хранить данные произвольного типа и составлять запросы прямо на Хаскеле.

tgz Jul 5 2013 at 15:34

По ссылке 500 — Internal Server Error
Молчу, молчу…

int_index Jul 5 2013 at 16:08

Хах, действительно. Еще вчера все было отлично, неужто Хабр завалил?

int_index Jul 5 2013 at 16:10

Можно еще здесь про Acid-State почитать.

kost_bebix Jul 4 2013 at 19:46

Persistent в Yesod очень даже хорошо выглядит, прямо поразительно красивее ООП-ORM'ов в некоторых местах. AcidState выглядит тоже неплохо.

zw0rk Jul 4 2013 at 20:10

А вы им пользовались? Я вот пытался — это мрак и ад, к сожалению. AcidState в этом плане гораздо симпатичней. Но хотелось бы большего :)

kost_bebix Jul 4 2013 at 20:16

Нет, как раз только сейчас балуюсь ими, потому и интересно узнать подробностей, что вам не понравилось конкретно.

zw0rk Jul 4 2013 at 20:20

Как только выходишь за пределы простых select-ов, начинается пляска и вырвиглазные конструкции, пропадает красота и лаконичность. Можно взять esqueletto, но там тоже довольно быстро начинаются проблемы. Собственно, некоторые проблемы персистеда описаны в мотивировке к esquletto blog.felipe.lessa.nom.br/?p=68

kost_bebix Jul 4 2013 at 20:22

А, ну тогда ясно. Да, мне как-то в последние годы удавалось все проблемы выражать в упрощенных моделях, без необходимости городить джойны или какой-то сложный SQL.

Esqueletto не трогал, за ссылку спасибо, гляну.

kost_bebix Jul 4 2013 at 20:26

> 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:

А, теперь понял о чем вы. Да, кошмар/

kost_bebix Jul 4 2013 at 21:50

Хотя, если честно, я так и не понял, чем автора не устроил

    maybeMichael <- selectFirst [PersonEmail ==. "michael@haskell.org"] []
    case maybeMichael of
      Nothing -> liftIO $ putStrLn $ "Sorry, noone found."
      Just michael -> liftIO $ print michael

в этом примере с выборкой по имейлу.

zw0rk Jul 4 2013 at 20:13

Очень хорошим вариантом мне представляется аналог вот такого (https://github.com/jonifreeman/sqltyped). Но ничего подобного для хаскеля я пока не видел.

kost_bebix Jul 4 2013 at 20:18

Ну, sqltyped на первый взгляд — это несколько совсем другое. В смысле, Persistent и AcidState стараются наоборот, абстрагироваться от SQL'а (а AcidState еще и от персистентности и прочего, можно использовать чистые IxSet всякие).

zw0rk Jul 4 2013 at 20:21

Непонятно зачем городить DSL вокруг DSL-я, который изначально предназначен для работы с SQL? :) А так мы убиваем двух зайцев сразу — не скрещиваем ежа и носорога и получаем (более-менее) type safety.

kost_bebix Jul 4 2013 at 20:54

Не очень понял. Суть «отгораживания от SQL» состоит в том, чтоб база данных (вообще персистентность объектов) была лишь деталью реализации, а не цертром вашей архитектуры. Ваши «бизнес-объекты» — обычные данные, а персистентность прикручивается незаметно в сторонке.

То есть, ORM как раз тем и занимается (в ООП-языках), что мапит ваши бизнес-объекты с описанием табличек, и «в идеале» вы БД можете прикручивать в последний момент. Robert Martin, в общем, уже сто раз рассказал лучше меня об этом.

zw0rk Jul 4 2013 at 21:06

Мартин не истина в последней инстанции. Во-первых, SQL стандартный тоже вполне может скрывать детали реализации (какая там конкретная реализация не столь важно, коль скоро мы не пишем в самом SQL ничего спеицифичного), а констрейн на СУБД в любом случае есть. Во-вторых, как только захочется использовать СУБД-специфичные вещи, то детали уже надо будет учитывать. Так что это вопрос подхода. В общем и целом, я считаю, что сам по себе SQL уже хороший уровень абстракции (для веба).

kost_bebix Jul 4 2013 at 21:13

Ну, имеется в виду не то, чтоб «скрывать детали реализации», а в том, что представление бизнес-моделей в хаскеле (тут, наверное, всякие алгебраические типы данных приходят на ум), или же в ООП-языках (обычно модели друг друга биндят прямо в виде моделей, а не через идентификаторы), мягко говоря «иногда» отличаются от того, что хранится в БД. В БД хранятся структуры данных, оптимизированные под представление, удобное для БД. Но оперировать же лучше данными (моделями), представленными в удобном виде для программиста.

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

По поводу «СУБД-специфичных вещей» — ну, собственно, суть не в том, чтоб никогда не писать голый SQL, а в том, чтоб трогать его только через некоторый абстрактный интерфейс, который скрывает детали БД и запросов, возвращая уже сами бизнес-объекты.

В общем, не хотелось бы уходить в политику. Предлагаю просто рассматривать два отдельных инструмента: ORM и SQL-абстрагирование и их качество. Их нужность обсуждать уже не хотелось бы :)

zw0rk Jul 4 2013 at 21:17

Ну я тоже не спорю, что иметь естественный для языка (и как можно более незаметный) «морфизм» из его способа описания данных и связей между ними и хранилищем — отличная штука. :)

5e8d631166 Jul 11 2013 at 07:54

я был бы сильно рад увидеть нечто подобное myBatis для хаскеля, потому как все эти умные стрелки очень клево смотрятся в статьях по матану, но в реальности запросы бывают весьма стремными и очень vendor-specific, так что абстрагирование их в каком-нибудь подключаемом текстовом файле и call-by-name было бы попросту отлично. Все попытки сделать ORM упрутся в Hibernate, оно вам надо?

kost_bebix Jul 11 2013 at 12:18

Если честно, не очень понятно, зачем SQL-запросы выносить в XML-файлы, в смысле, почему не построить красивое описание запросов прямо средствами языка (в Х-ле они позволяют это сделать). По поводу упирания в Hibernate не понимаю, почему вдруг, и при чем он здесь.

5e8d631166 Jul 11 2013 at 16:11

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

По поводу упирания в хибернейт — вот они как раз пытались сделать красивое описание.

kost_bebix Jul 11 2013 at 16:20

Ну, мне известно как минимум одна библиотека для питона — SQLAlchemy, и это в питоне, который тоже особо своей DSL'ностью никогда не выделялся. В хаскеле синтаксис и семантика позволит сделать еще приятнее.

Ну а то, что у джавы получаются монстры — наверное это проблема джавы. Вон, например, на хаскеле вполне неплохо выглядят parser combinator'ы (parsec, например). То есть даже парсеры (!) можно относительно красиво выражать средствами языка (такого я действительно нигде больше не видел).

zw0rk Jul 4 2013 at 21:11

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

kost_bebix Jul 4 2013 at 21:16

Не знаю кто как, но я как раз благодаря тому, что все «доставания данных» делал через отдельный интерфейс, смог на реальном проекте вынести кусок функционала в другую БД вполне просто. Бизнес-логика не была затронута совершенно, пришлось менять только интфейс выборки, что сильно облегчило задачу.

В то время, как «меняем БД на монго, пацаны!» встречается не часто, вынос отдельного куска по типу статистики или «больших ненужных данных» — вполне задача сегодняшнего дня.

Show the best of all time