This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
И ещё, что в функциональном программировании и Clojure вместо моделей данных как в ООП ORM`ы
Имею в виду, что если нет необходимости в ORM, то в какую сторону мне мышление сломать
как раз когда не нужно ORM
использовал его как раз с постгрёй
для динамических запросов не подойдет он
когда нужно менять чуть-чуть структуру запроса
а часто нужно так делать — строить запрос налету
повторно использовать кусочки запросов тоже не получится, например, выбрать данные и посчитать количество по этому запросу — будут два разных файла и надо поддерживать их оба
в java это все хорошо делают jOOQ и QueryDSL, например
в Clojure в этом плане https://github.com/korma/Korma похожа
генератора только нет в ней, чтобы по схеме базы наделать defentity
, удобно было бы
Почему повторно не получится? Все запросы можно определять в одном файле как именованные функции
Да, в этом файле будет много дублирования, но в SQL это и не проблема, имхо
у korma есть проблемы с postgers jsonb полями, так что если собираетесь их использовать, то смотрите на что-то другое
>>>The problem with SQL is that it's a custom language. Using SQL from other languages causes a host of other problems - problems that are orthogonal to querying a database. These problems are examples of accidental complexity, complexity in an application caused by the tool used to solve a problem rather than the problem itself.
Там есть ссылка на разговор Рича. Я не скажу точно тот этот доклад или нет, но он как-то говорил про проблемы SQL. В том числе, что для SQL нет API Копировать-вставлять SQL наверное можно, но писать этот SQL руками для сложных выборок не очень удобно
в текущем проекте у нас есть запрос примерно в 1000 строчек, у которого есть пару десятков вариаций, когда меняется предикат немного
не могу представить как это сделать статическими запросами
просто наверное разные задачи у всех, можно и несколько библиотек для работы с данными в одном проекте использовать если что
Ну да, для фильтров всяких собирать запросы динамически наверное единственный разумный выход
для некоторых фильтров еще могут понадобиться дополнительные join'ы
и еще если это дело сортировать, то может понадобиться в проекцию добавлять дополнительные поля
там много нюансов
Мы активно используем honeysql и небольшую собственную обертку над ней. Это дата дсл. Так же в одном проекте хорошо легла prizmatic schema для коэрсинга и валидации.
Мы пользуемся в основном самописной, но есть ещё https://github.com/ckuttruff/clj-sql-up и https://github.com/weavejester/ragtime
Для поддержки jsonb и массивов в postgresql - https://gist.github.com/niquola/91d94e1a51291e7db001
Для поддержки jsonb и массивов в postgresql - https://gist.github.com/niquola/91d94e1a51291e7db001
Вобщем honey библиотека, а korma фреймворк. Мы дописали например eager-loading для honey на 50 строчек - если интересно могу выковырять
для сильных духом есть Cassandra, как замена Mongo
@delaguardo а вы касандрой пользовались?
под метрики использовали, приколько получилось, но есть проблема с тем как представить данные
для кассандры важно по каким ключам группируются данные
в итоге перехали на influx, хапнули с ним тонны фэйлов и сейчас разворачиваем кластер из PostgresXL
@linuccio в принципе там разумная ценовая политика. Pro бесплатен для 2 пиров и одного транзактора, других ограничений нет. По сути это означает, что - для одного пира, т.к. второй лучше оставить свободным для Datomic Console. Весь jvm-процесс - это один peer, поэтому можно цеплять много сервисов, если разворачивать их в одном из джавовских аппликейшн контейнеров. Мы так и делаем, чтобы архитектура не зависела от прайса. Апгрейд на большее количество пиров подразумевает больше нагрузок, и на серверы без всякого дейтомика денег уйдет еще больше чем на его лицензию.
К сожалению, не смотря на то, что дейтомик обращается со стораджем чанками, а не отдельными записями, это не означает, что DynamoDB укладывается в бесплатный лимит.
Поэтому на амазоне сейчас будет, в минимальной (но production) конфигурации, прядка 40 долларов: 20 за t2.small для транзактора и 20 за DynamoDB.
Посмотрел на Postgres (давно не смотрел, в основном MySQL использовал) - производительность впечатляет
@ilshad: я так понимаю вы его в продакшене крутите? можете поделиться цифрами как оно себя под нагрузкой ведет?
жаль, хотелось бы узнать насколько сейчас Datomic готов для высоких нагрузок
@delaguardo: пробегись по гугл-группе дайтомика
@ilshad: не заглядывал туда, спасибо