https://www.playframework.com/documentation/2.5.x/ScalaCompileTimeDependencyInjection Application entry point

load'у нужен Application, а не Future[Application], вот в чем загвоздка. Вот если б совсем-совсем entry-point, чтобы можно было вызвать в class Main extends App {} , то да

я ковырялся в исходниках, там можно найти такую точку

посмотри, как сделан стандартный guice loader, и там будет эта точка где-то рядом, если я не ошибаюсь

load'у нужен Application, а не Future[Application], вот в чем загвоздка. Вот если б совсем-совсем entry-point, чтобы можно было вызвать в class Main extends App {} , то да

Custom application loader

Точка guice

походу оно: https://github.com/playframework/playframework/blob/38abd1ca6d17237950c82b1483057c5c39929cb4/framework/src/play/src/test/scala/play/api/libs/TemporaryFileCreatorSpec.scala#L87

В конфигее можно указать свой и там творить всякое

В конфигее можно указать свой и там творить всякое

так ты указываешь класс, в котором синхронный load :)

А что толку, загрузишь ты сначала в базу что то а потом стартуешь приложение. (пользователи видят 404 10 сек) Или сначала стартуешь приложение (пользователи видят "Загрузка" 10 сек) а потом загружаешь

надо именно свой entry-point делать. Но вообще, скорее всего задачу придется решать иначе :)

Вообще, можно заблокировать фьючу, чё такого то?

или грешно?

+ все равно для норм работы данные надо

Грешно

да не, просто вдруг есть "более лучший" путь :)

Однозначно есть ) Это сейчас похоже на аццкие костыли.

Однозначно есть ) Это сейчас похоже на аццкие костыли.

У тебя все похоже на костыли если это не акка

У тебя все похоже на костыли если это не акка

Play вроде с Аккой дружит ?

Подружить можно все что угодно

Так говорите, будто Any => Unit не костыль

*картинка с кривой рожей*

Так говорите, будто Any => Unit не костыль

А разве костыль?)

костыль конечно, не костыль как минимум ThisActorMessage => Unit, где sealed triat ThisActorMessage

[немного оффтопа] Кстати, попробовал для поиска duckduckgo.com, помню тут про него говорили. Даже для английского языка качество поиска так себе :( Часто приходится искать в гугле [/оффтоп]

Немного наброшу говна. sealed trait Wtf object Wtf { case object Foo extends Wtf case object Bar extends Wtf case object Baz extends Wtf } val xs = Set(Wtf.Foo, Wtf.Bar) // scala.collection.immutable.Set[Product with Serializable with Wtf] = Set(Foo, Bar) Собственно, WTF, товарищи? Петрашко говорил, что мощная система типов жы

Может из за того что сет нековариантный?

Может из за того что сет нековариантный?

List - то же самое

Немного наброшу говна. sealed trait Wtf object Wtf { case object Foo extends Wtf case object Bar extends Wtf case object Baz extends Wtf } val xs = Set(Wtf.Foo, Wtf.Bar) // scala.collection.immutable.Set[Product with Serializable with Wtf] = Set(Foo, Bar) Собственно, WTF, товарищи? Петрашко говорил, что мощная система типов жы

Что не так?

Правильный тип же

Что не так?

Очевидно, xs должно иметь тип Set[Wtf]

Потому что Wtf - это общий супертип для Wtf.Foo и Wtf.Bar

а "Product with Serializable with Wtf" - это говно какое-то

Нет не очевидно, т.к. case добрасывает родителей в object

Всё правильно вывел

не понял "добрасывает родителей"

а…

Ключевое слово case добавляет имплементации Product и Serializable в класс и объект

дада, я понял )

Можешь добавить в trait

Эти типы

тогда наименьшим общим предком будет просто Wtf

да, ты прав :) неочевидно, но все верно

Врядли :D Но для нормального десктопного приложения ничего лучше C++/Qt на текущий момент нет. Надеюсь, скоро что-нибудь приедет из раста, потому что С++ адовенько после скалы использовать, конечно

Это утверждение верно для линукса

Это утверждение верно для линукса

Я говорил скорее о кросс-платформе

кто сегодня делает приолжения для одной платформы?

Кровавый энтерпрайз

не, ну понятно, что можно найти. Но я говорю о _нормальной_ разработке

В Play завезли асинхронный кэш https://www.playframework.com/documentation/2.6.x/ScalaCache#accessing-the-cache-api

В Play завезли асинхронный кэш https://www.playframework.com/documentation/2.6.x/ScalaCache#accessing-the-cache-api

фууу какой он низкоуровневый,но как раз подойдёт как бэкенд к Tinkoff macroCache

В Play завезли асинхронный кэш https://www.playframework.com/documentation/2.6.x/ScalaCache#accessing-the-cache-api

а зачем фьюча? он там что, распределенный?

давайте ещё асинхронные сеттеры и геттеры делать

а зачем фьюча? он там что, распределенный?

У тебя сам процесс вычисления при cache miss может быть асинхронный

Там EhCache под капотом, в теории он может быть распределнным

Допустим, ты в монгу лезешь, если не не найдено

getOrElseUpdate[A](key: String, expiration: Duration = Duration.Inf)(orElse: ⇒ Future[A])(implicit arg0: ClassTag[A]): Future[A]

стремная штука, но какой-то резон есть

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

я понял, и оно мне не нравится

Вот как ты можешь понять, что ты понял

например, там сломана атомарность

например, там сломана атомарность

каким образом?

например, там сломана атомарность

атомарность чего?

атомарность транзакционно-дюрабельной конкуретности кеша

каким образом?

что будет, если другой поток засетает что-то, пока фьюча делается?

Вообще, такой код хорош до момента, пока ничего не сломано

что будет, если другой поток засетает что-то, пока фьюча делается?

засетает что? Это же кеш

ERROR: S client not available

что угодно, отличное от будущей фьючи

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

Не пойму, где ты увидел, что оно сломано

если тебе нужно инвалидировать кеш, для этого есть remove, кеш вполне может даблчекнуть инвалидацию после возврата фьючи

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

не обязательно

set(key: String, value: Any, expiration: Duration = Duration.Inf): Future[Done]

remove(key: String): Future[Done]

вот remove может дожидаться get ов на этот же key

и set

Немного наброшу говна. sealed trait Wtf object Wtf { case object Foo extends Wtf case object Bar extends Wtf case object Baz extends Wtf } val xs = Set(Wtf.Foo, Wtf.Bar) // scala.collection.immutable.Set[Product with Serializable with Wtf] = Set(Foo, Bar) Собственно, WTF, товарищи? Петрашко говорил, что мощная система типов жы

что бы так не было принято писать sealed trait Wtf with Product with Serializable

как ты просто глядя на туториал смог понять, что оно сломано?

как ты просто глядя на туториал смог понять, что оно сломано?

на апи

посмотри все популярные библиотеки, там все ADT так объявлены

Можешь добавить в trait

Эти типы

тогда наименьшим общим предком будет просто Wtf

на апи

ну как видим из него не следует

что бы так не было принято писать sealed trait Wtf with Product with Serializable

супер ) спасибо!

следует лишь то, что кто-то делает преждевременные выводы

тогда наименьшим общим предком будет просто Wtf

да-да, тебе тоже спасибо большое )

либо банальный сет/гет будет блочить, либо вон та фигня выше с не тем велью

либо банальный сет/гет будет блочить, либо вон та фигня выше с не тем велью

Как я уже сказал, геты могут даблчекаться после возврата на инвалидацию.

Неблокирующе

Как я уже сказал, геты могут даблчекаться после возврата на инвалидацию.

1 с монги прийдет через 5 сек 2 вот уже тут и есть запрос на велью что делать?

можно ещё заигнорить ответ монги, что тоже так себе

Приходит из монги - версия ключа совпадает? 1да - вернуть 2 нет - посмотреть был делит или сет,

и вернуть то, что было позже

что ты называешь "версией ключа"?

один из вариантов даблчека

для ключей хранятся инкрементальные версии

это просто одно из предположений, как это может быть реализовано