Модель у нас не очень сложная, поэтому сознательно отказались от ORM.
Но я конечно понял твою мысль.
Я так понимаю, что реактивность не просто в пуле тредов, а еще в том, как с ним взаимодействовать (можно использовать акторы например, или просто фьючи). А еще я не знал, но к некоторым СУБД разрабатываются асинхронные коннекторы (Postgres и MySQL)
Интересно было почитать. Смешно, когда я прочитал слово Oracle, который вы любите и умеете готовить, я в первую очередь подумал о джаве, а совсем не о СУБД.
Скальный паттерн освобождения ресурсов, который вы использовали в execute, называется Loan: wiki.scala-lang.org/display/SYGN/Loan. Необходимая вещь, конечно же.
Еще очень правильным решением было отказаться от ORM, вот и ребята из Слика считают, что ORM — большая ошибка для крупных проектов, что реляционные абстракции и абстракции ОО плохо соответствуют друг другу, и поэтому не стоит маскировать реляционные таблички и кортежи под объекты: slick.typesafe.com/talks/scalax2012/Slick_ScalaExchange_2012.pdf, слайд 11.
Мне кажется, что соединение с БД проще сделать неявным параметром у запроса, чтобы не передавать его каждый раз в дополнительных скобках.
Я сильно подозреваю, что Идея поняла вашу строковую интерполяцию для sql потому, что в других движках тоже есть похожие с такими же названиями. В Слике есть. Вообще, я остаюсь большим поклонником Слика, жалко, что Оракл-плагин у него платный, но для «Тинькова» наверно это не так важно. И для Монго они тоже активно разрабатывают плагинчик.
Реактивность для jdbc обычно достигается выделением фиксированого количества тредов под соединения с БД, а реактивный код к этим тредам обращается. Это позволяет снять пиковую нагрузку на БД, когда количество замороженных тредов начинает зашкаливать. Этим активно пользуются play-разработчики, например.
Да, все правильно: Akka как раз сделана с большой оглядкой на эрланг и с теми же самыми акторами. Не знаю, что не так было с эрлангом, может быть, авторы ожидают более широкого применения своей новой платформы. На ней акке сейчас много чего делают, из общедоступного Play framework для веба и Spray для реста, да и сами акторы из акки переехали в язык, а их предыдущая версия была послабей.
Спасибо за перевод, большая работа и неплохой язык! У меня есть пара поправок:
1) В перечислении характеристик реактивных приложений вы пишите:
реагируют на события
Ориентированность на события означает наличие следующих качеств.
На самом деле она не обозначает наличия следующих качеств, а делает их возможными, является необходимой для них. В оригинале: «the event-driven nature enables the following qualities».
2) Последнее предложение манифеста у вас:
Мы ждём, что системы, число которых стремительно растёт, в ближайшем будущем будут следовать этому манифесту.
На самом деле они ждут, что число систем, которые следуют манифесту, будет стремительно расти. Оригинал: «We expect that a rapidly increasing number of systems will follow this blueprint in the years ahead».
Ответ вам про событийную ориентированность случайно попал в комментарии первого уровня. Еще я отредактировал текст статьи и вернул туда кусок с пересказом реактивного манифеста.
Поменял название поста. Изначально в нем был сжатый пересказ реактивного манифеста, в котором разъясняется суть подхода, но так как его перевод уже есть на хабре целиком, я удалил эту часть с пересказом.
Ответ на ваш вопрос как раз в этом манифесте. Если вкратце, то ориентированность на события — одна из четырех характеристик реактивного подхода и именно она делает возможными остальные характеристики:
масштабируемость (легкий перенос в кластера и эластичное изменение используемых ресурсов в зависимости от нагрузки, достигается за счет построения всего взаимодействия в системе на асинхронных неблокирующих акторах),
отказоустойчивость (самовосстановление системы за счет иерархии акторов-супервайзеров, как в Эрланге),
и быстрый отклик вне зависимости от загрузки и сбоев.
А также: требования реактивной архитектуры запрещают блокирующие операции по все системы, приветствуют неизменяемые данные и асинхронное взаимодействие, а ядром системы становятся акторы.
Я так понимаю, что реактивность не просто в пуле тредов, а еще в том, как с ним взаимодействовать (можно использовать акторы например, или просто фьючи). А еще я не знал, но к некоторым СУБД разрабатываются асинхронные коннекторы (Postgres и MySQL)
Скальный паттерн освобождения ресурсов, который вы использовали в execute, называется Loan: wiki.scala-lang.org/display/SYGN/Loan. Необходимая вещь, конечно же.
Еще очень правильным решением было отказаться от ORM, вот и ребята из Слика считают, что ORM — большая ошибка для крупных проектов, что реляционные абстракции и абстракции ОО плохо соответствуют друг другу, и поэтому не стоит маскировать реляционные таблички и кортежи под объекты: slick.typesafe.com/talks/scalax2012/Slick_ScalaExchange_2012.pdf, слайд 11.
Мне кажется, что соединение с БД проще сделать неявным параметром у запроса, чтобы не передавать его каждый раз в дополнительных скобках.
Я сильно подозреваю, что Идея поняла вашу строковую интерполяцию для sql потому, что в других движках тоже есть похожие с такими же названиями. В Слике есть. Вообще, я остаюсь большим поклонником Слика, жалко, что Оракл-плагин у него платный, но для «Тинькова» наверно это не так важно. И для Монго они тоже активно разрабатывают плагинчик.
Реактивность для jdbc обычно достигается выделением фиксированого количества тредов под соединения с БД, а реактивный код к этим тредам обращается. Это позволяет снять пиковую нагрузку на БД, когда количество замороженных тредов начинает зашкаливать. Этим активно пользуются play-разработчики, например.
1) В перечислении характеристик реактивных приложений вы пишите: На самом деле она не обозначает наличия следующих качеств, а делает их возможными, является необходимой для них. В оригинале: «the event-driven nature enables the following qualities».
2) Последнее предложение манифеста у вас: На самом деле они ждут, что число систем, которые следуют манифесту, будет стремительно расти. Оригинал: «We expect that a rapidly increasing number of systems will follow this blueprint in the years ahead».
Ответ на ваш вопрос как раз в этом манифесте. Если вкратце, то ориентированность на события — одна из четырех характеристик реактивного подхода и именно она делает возможными остальные характеристики:
А также: требования реактивной архитектуры запрещают блокирующие операции по все системы, приветствуют неизменяемые данные и асинхронное взаимодействие, а ядром системы становятся акторы.