В акке ввели Done

типа Future[Done]

насколько понимаю, как раз чтобы не было каста в юнит?

Ну и intention как бы лучше передается )

done просто болванка как и юнит, насколько помню

Если она компилятором не откидывается, то она уже свое дело делает

я все равно за опцию компилятора 1) не аккой единой 2) накосячить можно случайно и не заметить

не могу придумать случая, когда это Future[Unit] приведёт к проблеме. Может кто-нибудь пример привести?

проблемы при интеграции с джавой

Очень странный кейс

Тоже не вижу проблем

это как раз и было мотивацией тайпсейфа для смены Unit на Done

Если говорить о фреймворке типа акки, то да. Но что плохого в использовании Future[Unit] у себя в коде? О каких ошибках идет речь?

А кто нибудь юзал gRPC ?

А почему нельзя конкретный тип вернуть? Об чем речь:(

А почему нельзя конкретный тип вернуть? Об чем речь:(

А если конкретный тип не нужен? Например, у вас есть слой доступа к данным. Из вашего слоя бизнес логики вы дергаете метод - удали запись юзера. Внутри слоя доступа к данным вы делаете запрос к бд, ждете ответ, разбираете этот ответ (а там не Future[Unit], там какой-нибудь Future[DbResponse]). И уже результат в бизнес слой возвращаете в виде Future[Unit], потому что бизнес слою интересно только сам факт того, прошло ли удаление удачно, или нет. А если прошло неудачно - то с какой ошибкой. И это как раз случай Future[Unit]. А теперь повторю вопрос - где тут подвох, о котором говорили выше?

Нужно стараться избегать Unit, потому что любое выражение "проглатывается". К примеру, пишем future.map, внутри что-то делаем. Потом решаем, что просто что-то делать не достаточно, хотим внутри футуру зафигачить, но вдруг нас тут отвлекают и мы забываем map заменить на flatMap, переходим в другое место и фигачим код дальше. Ха-ха. Если б был бы указан конкретный тип, то компилятор бы ругнулся

всем привет. Slick+hikariCP+postgresql , делаю кучу запросов подряд, выдает вот такую радость: Pool stats (total=10, active=0, idle=10, waiting=0) но : HikariPool-10 - Cannot acquire connection from data source org.postgresql.util.PSQLException: ����������: ����������������, ������ �������������� ���������� ���������������� естесственно, у постгре не осталось свободных коннектов, из 100 забито 100. очень глупый вопрос, а как в слике корректно очищать ресурсы? потому как если делать db.close то это , как я понял не коннект закрывает а вообще пул останавливает. This shows that after every request the db connection is returned to the pool within db.run(...) and db.close is not required. видимо , я не умею готовить слик %)

обычно это значит, что кто-то напихал фьюч куда не стоит, из-за чего слик не может следить за пулом

а куда не стоит? db.run возвращает фьючу, в onComplete я делаю respond ответа на страницу.

честно говоря третий не юзал, может там что-то уже по иному во 2ом никаких стримов не было, по неопытности фьючу засунул в транзакцию, из-за чего слик не мог освобождать ресурсы (фьюча мгновенно возвращается, но коннект еще не свободен в этот момент) ну и у других аналогичный косяк часто видел

В тестах репозиториев на mysql такое было. Просто стартует много тестов и слик вываливается с такой же ошибкой.

ну, вообще, падают те запросы, в которых необходимо выполнить два запроса в одной транзакции. точнее: есть запрос X , написанный на plain sql(специфический очень), есс-но в слике его нельзя использовать как подзапрос, возвращает он DBAction. db.run { val userGroupsQuery = groupsDao.recursiveGroupsForUser(userId) map (_.map(_._1)) val query = userGroupsQuery.flatMap{ groupsId => val access = testDao.searchAccessQuery(userId, testId, groupsId) val testQuery = tests.filter{t => (t.testid in access)|| (t.testid === testId && t.creatorid === userId) }.map(_.testid) tasks.filter(t => t.taskid === taskId && (t.testid in testQuery)).result } query.map(_.headOption) }

вот пара таких запросов и вешают все

честно говоря третий не юзал, может там что-то уже по иному во 2ом никаких стримов не было, по неопытности фьючу засунул в транзакцию, из-за чего слик не мог освобождать ресурсы (фьюча мгновенно возвращается, но коннект еще не свободен в этот момент) ну и у других аналогичный косяк часто видел

вообще , буду разбираться, спасибо

?

нашел я свою проблему, извините, что отвлек своей простыней - я нарукожопил при создании пула

Наверное избитый вопрос по play, но я тем более удивлён, что не нашел на него ответ: если у меня есть пул коннекшнов к БД и я хочу работать с ним самостоятельно (не средствми play), как добиться того, чтобы в dev режиме не происходил реконнект после reload? Пробовал inject-ить класс, инициирующий коннекшн, но он пересоздается каждый раз ☹️

Что все так на этом Play'e зациклены? Finatra, Scalatra, Collosus, akka-http, finch, Xitrum, полно же...

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

Что все так на этом Play'e зациклены? Finatra, Scalatra, Collosus, akka-http, finch, Xitrum, полно же...

в них тоже наверняка какая-нибудь подстава галактического размера

после полугода работы с akka-http иногда начинаешь скучать по плею и встроенным в него плюшкам

В большинстве перечисленных мною фреймворков только одна подстава - это не fullstack фрэймвоки, собираем свой космический корабль сами.

Ну в Finatra подстава с Футурами, они там твиттеровские и приходится использовать Bijection и специфичные имлициты.

https://ru.wikipedia.org/wiki/Футура

По-моему, Play тут ни при чем. Там для работы с БД используются отдельные библиотеки, которые точно также можно использовать и с другими фреймворками

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

При изменении сорцов релоад вызывает пересборку и рестарт. Это одна из плюшек плея. Очевидно, что никакое состояние в памяти не сохранится.

Т.е., нужно чтобы при рестарте приложения, коннект каким-то магическим образом сохранялся?)

именованные JDBC datasource каким-то образом остаются в памяти - потому что они потом ругаются, что уже существуют datasource с таким именем

вот я и подумал, что раз они как-то переживают рестарт (по сути - переживает рестарта HashMap, которая хранит соответствие имя->datasource), значит каким-то образом можно "сохранить" некий класс при рестарте

тем более - там же не обычный рестарт, там ClassLoader подменяется - в общем, какая-то магия

кто-нибудь использует у себя akka-quartz-scheduler?

Да, юзаем это поделие.

Да, юзаем это поделие.

как-нибудь можно из актора, который принял сообщение от шедулера дропнуть job_у?

Можно, доберусь до кода/компа сообщу как, если вы раньше не увидите)

Можно, доберусь до кода/компа сообщу как, если вы раньше не увидите)

спасибо, буду признателен, курю доки сейчас просто , пока не нашел

привет! Кто-то знает как в scalacheck генератор String заставить генерировать только читаемые строки?

postgres недоволен

Gen.alphachar?

спасибо, нашел уже

Gen.identifier

Друзья, все еще ищу докладчиков на московскую встречу скалалазов https://data-monsters.timepad.ru/event/339285/ Можно писать прямо в телеграм или на почту aleksey.fomkin@gmail.com

Чо как вам первый день скала дейс?

Отлично!

А что, уже начался?

Одеркски признал что дот нотация рулит и он со своим x map f был не прав

Самая важная новость.

То есть теперь items map { item => }

Это не кошерно?

Хз, по-моему, очень кошерно. Количество визуального мусора по крайней мере минимально, а это большой плюс для читаемости

Надо будет специально помечать infix если ты хочешь писать с пробелом. да некошерно. Кстати, можно будет писать pairItems map ((x,y) => ..) без {case (x,y) => ...}

остается ; добавить в конец строк и можно идти Гослингу сдаваться

ERROR: S client not available

;)

Ну да холиварная темка.

Брошу все, уйду в хаскель.

лучше в идрис

И будешь на шее у мамки сидеть без работы

Все мы там будем

Вообще интересное у него выступление было (частично повторяет какое-то январское). по мелочи много чего добавят в язык вместе с дотти.

И будешь на шее у мамки сидеть без работы

Я устроюсь куда-нибудь техдиректором и перетащу контору на хаскель. Всегда так делаю.

Хаскель - сила, скала - могила.

Кто не в компайл-тайме, тот под нами!

лучше в идрис

Еще лучше язык Макса Сохатского в продашкен. Там где HoTT и вот это все.

Но я кстати не вижу никаких движух особых и преимуществ в хаскеле. ну так взгляд со стороны. есть вот ликвид хаскель чтобы по вене пускать: https://ucsd-progsys.github.io/liquidhaskell-tutorial/01-intro.html Но для простых смертных чего-то типа акка/спарк/плей, чтобы сразу начать ехать - беда

А здесь вот объяснят, наверное, за стримы, akka typed, cluster sharding, akka persistence и прочие микросервисы. В общем, движение!

Одеркски признал что дот нотация рулит и он со своим x map f был не прав

а как тогда писать?

с распределенкой в хаскеле традиционно беда

это язык для написания компиляторов :)

языку сохацкого до гомотопических типов по моему еще как до луны :)

у них там основная победа в хитром кодировании рекурсии

а шо касается точек в скале, я их не ставлю только для методов типа max или union, где есть какой то намек на симметрию аргументов

но то конечно дело вкуса

Обьясните на примере почему в языке нету гомотопических типов ?

Hott начал активно развиваться в 2006-08, позже чем скала чисто по времени. Ну, а главное - strategic Scala Style: Principle of Least Power - язык не будет комплектоваться такими оверкиллами ботаников как dependet types, higher inductive types и применениями в гомотопии. для математиков это основная фишка - гомотопичность двух путей доказательства, но для практического языка - где это вообще может пригодится? Лучше скажи пример, где hott нужен :)

dependent types - оверкилл для ботаников?

мне бы тоже настоящих dependent types в Scala...

да они настоящие весьма

просто грязно определяются

Внимание, очень нубский вопрос. Как запустить sbt проект демоном? Есть стандартные средства? Или через шел скрипты только делать?

это вещи которые люди в реальных проектах не пользуются

я бы сказал что математические теории и все что имеет прямое отношение к математике должно быть запрещено для программирования в "индустрии"

в Go пошли по подобному принципы и потому язык быстро стал популярным