Уже не помню подробности, но, кажется, удаление не помогало. Я в конце концов вернул DEFAULT и в целом сглаживание удовлетворительное. Больше волнует, что шрифты немного изменились, в некоторых местах имеют проблемы с отступами и вообще немного непривычные.
В общем. надо будет разобраться как его удалить нормально.
Ну, мне известно как минимум одна библиотека для питона — SQLAlchemy, и это в питоне, который тоже особо своей DSL'ностью никогда не выделялся. В хаскеле синтаксис и семантика позволит сделать еще приятнее.
Ну а то, что у джавы получаются монстры — наверное это проблема джавы. Вон, например, на хаскеле вполне неплохо выглядят parser combinator'ы (parsec, например). То есть даже парсеры (!) можно относительно красиво выражать средствами языка (такого я действительно нигде больше не видел).
Если честно, не очень понятно, зачем SQL-запросы выносить в XML-файлы, в смысле, почему не построить красивое описание запросов прямо средствами языка (в Х-ле они позволяют это сделать). По поводу упирания в Hibernate не понимаю, почему вдруг, и при чем он здесь.
Не знаю кто как, но я как раз благодаря тому, что все «доставания данных» делал через отдельный интерфейс, смог на реальном проекте вынести кусок функционала в другую БД вполне просто. Бизнес-логика не была затронута совершенно, пришлось менять только интфейс выборки, что сильно облегчило задачу.
В то время, как «меняем БД на монго, пацаны!» встречается не часто, вынос отдельного куска по типу статистики или «больших ненужных данных» — вполне задача сегодняшнего дня.
Ну, имеется в виду не то, чтоб «скрывать детали реализации», а в том, что представление бизнес-моделей в хаскеле (тут, наверное, всякие алгебраические типы данных приходят на ум), или же в ООП-языках (обычно модели друг друга биндят прямо в виде моделей, а не через идентификаторы), мягко говоря «иногда» отличаются от того, что хранится в БД. В БД хранятся структуры данных, оптимизированные под представление, удобное для БД. Но оперировать же лучше данными (моделями), представленными в удобном виде для программиста.
То есть, я к тому, что считаю, что нужно иметь как один, так и другой механизм. Отдельно ORM, связывающий данные с персистентностью, и отдельно язык запросов, который позволяет оперировать SQLем в виде, более приятным, нежели строки.
По поводу «СУБД-специфичных вещей» — ну, собственно, суть не в том, чтоб никогда не писать голый SQL, а в том, чтоб трогать его только через некоторый абстрактный интерфейс, который скрывает детали БД и запросов, возвращая уже сами бизнес-объекты.
В общем, не хотелось бы уходить в политику. Предлагаю просто рассматривать два отдельных инструмента: ORM и SQL-абстрагирование и их качество. Их нужность обсуждать уже не хотелось бы :)
Не очень понял. Суть «отгораживания от SQL» состоит в том, чтоб база данных (вообще персистентность объектов) была лишь деталью реализации, а не цертром вашей архитектуры. Ваши «бизнес-объекты» — обычные данные, а персистентность прикручивается незаметно в сторонке.
То есть, ORM как раз тем и занимается (в ООП-языках), что мапит ваши бизнес-объекты с описанием табличек, и «в идеале» вы БД можете прикручивать в последний момент. Robert Martin, в общем, уже сто раз рассказал лучше меня об этом.
> 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:
А, ну тогда ясно. Да, мне как-то в последние годы удавалось все проблемы выражать в упрощенных моделях, без необходимости городить джойны или какой-то сложный SQL.
Ну, sqltyped на первый взгляд — это несколько совсем другое. В смысле, Persistent и AcidState стараются наоборот, абстрагироваться от SQL'а (а AcidState еще и от персистентности и прочего, можно использовать чистые IxSet всякие).
Ну, я подробностей не знаю, но в статье на developers.org.ua, где обсуждали «как обналичить заработанные за рубежом деньги», естественно, упоминали и payoneer, и то, что счет вы не открываете в зарубежном банке. Тем не менее, говорили, что деятельность их платежных карточек не законна.
В общем. надо будет разобраться как его удалить нормально.
Возможно вы имели в виду: кампанию?
Ну а то, что у джавы получаются монстры — наверное это проблема джавы. Вон, например, на хаскеле вполне неплохо выглядят parser combinator'ы (parsec, например). То есть даже парсеры (!) можно относительно красиво выражать средствами языка (такого я действительно нигде больше не видел).
в этом примере с выборкой по имейлу.
В то время, как «меняем БД на монго, пацаны!» встречается не часто, вынос отдельного куска по типу статистики или «больших ненужных данных» — вполне задача сегодняшнего дня.
То есть, я к тому, что считаю, что нужно иметь как один, так и другой механизм. Отдельно ORM, связывающий данные с персистентностью, и отдельно язык запросов, который позволяет оперировать SQLем в виде, более приятным, нежели строки.
По поводу «СУБД-специфичных вещей» — ну, собственно, суть не в том, чтоб никогда не писать голый SQL, а в том, чтоб трогать его только через некоторый абстрактный интерфейс, который скрывает детали БД и запросов, возвращая уже сами бизнес-объекты.
В общем, не хотелось бы уходить в политику. Предлагаю просто рассматривать два отдельных инструмента: ORM и SQL-абстрагирование и их качество. Их нужность обсуждать уже не хотелось бы :)
То есть, ORM как раз тем и занимается (в ООП-языках), что мапит ваши бизнес-объекты с описанием табличек, и «в идеале» вы БД можете прикручивать в последний момент. Robert Martin, в общем, уже сто раз рассказал лучше меня об этом.
> Or you could do it in one query using the ad hoc Database.Persist.Query.Join.Sql module:
А, теперь понял о чем вы. Да, кошмар/
Esqueletto не трогал, за ссылку спасибо, гляну.
/people/ — для списка
/people/123 — для конкретного
То есть, слеш в конце определяет, список это или нет. Это особенно удобно для под-ресурсов типа:
/account/profile — для профиля «текущего» юзера. Сразу ясно, что никакой это не список, а конкретный ресурс.