А в чем разница с простым методом? В переиспользовании коннекта?

А в чем разница с простым методом? В переиспользовании коннекта?

если много потоков пишут\читают в\из БД то мэйлбокс дает синхронизацию их доступа к БД

Уже ответили :(

Хм, понятно

это такой лок, но с очередью вызовов чтобы внешние источники не лочились, а накидали запросов в ящик и пошли своими делами заниматься

Но обычно они ждут ответа

так или иначе

это такой лок, но с очередью вызовов чтобы внешние источники не лочились, а накидали запросов в ящик и пошли своими делами заниматься

если вызовы без Reply

если вызовы без Reply

вот да. это редкость. потому что ответ хотя бы вида Ok/Error нужен

PostAndReplyAsync

Ну да, это то что я выше ченелом назвал.

Короче, лично мне мейлбоксы нравятся

Очень удобная штука для хранения стейтов

Хотя плохо, что нативно к нему эвенты не приделали

Хотя плохо, что нативно к нему эвенты не приделали

тогда теряется весь смысл акторов

Ну фиг знает. МНе было бы полезно

н никто не мешает тебе взять в замыкание актора какой-нибудь subject и в него пушить event а ля Rx

Ну то на то

А как ты представляешь себе ивенты там?

Ну смотри

Задача такая

Напиши код)

Хотя плохо, что нативно к нему эвенты не приделали

В фшарпе же эвенты как объекты, можешь передать

Если я правильно понял

Ну можно, конечно, через сообщения просовывать

Там нормально через fun работает все

А как запросы выглядят?

col.Find predicate|>List.of Seq

let find predicate =...

А можно глупый вопрос?

Тоесть при работе с базой всегда должен быть меилбох?

А как он должен создавать/убиваться. Пер реквест?

Ну я создаю один

На все время жизни

УБиваетя по токену

col.Find predicate|>List.of Seq

Я не уверен, что это эффективное решение.

На все время жизни

Ну я насколько я понимаю этот вариант не годится если много коннкшенов нет? + Не совсем понимаю чем такой вариант отличается от вара без меилбоакса

Скорее всего оно неэффективное

Может подсказать кто-то?

Мейлбокс нужен для организации очереди запросов

Мейлбокс нужен для организации очереди запросов

Но в твоём случае можно было не только меилбокс заюзать, а любую очередь нет?

Но в твоём случае можно было не только меилбокс заюзать, а любую очередь нет?

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

Опять же, я легко могу прикрутить, например, определенные действия при обновлении объектов

Но это уже про эвенты скорее

Скорее всего оно неэффективное

Суть квотейшенов же в том, что из них составляется Query.

Который потом компилится в ту же лямбду

Который потом компилится в ту же лямбду

С чего бы это?

Но в целом соглашусь, что для сложных запросов удобнее

С чего бы это?

А, вру

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

Наверное. Спасибо

Там же поиск по BSON, да

https://github.com/mbdavid/LiteDB/wiki/Queries

Кстати, к вопросу об акторах - как делают бродкасты правильно?

Кстати, к вопросу об акторах - как делают бродкасты правильно?

берут акку :peka:

А в ней что используют?

Акка у меня пока не влезет по фреймворку

ActorSelection по вайлдкардам например и туда Send

или хитрых акторов которые знают про акторов

А если хочется, чтобы не знали?

ты как бы пихаешь ему, а он пихает кому знает

А как ты хочешь броадкаст устроить если ты не знаешь кому броадкастить?

Ну файрить эвенты

Кому надо, тот подпишется

А, в EventStream пихай

там есть в акке системная шина

В общем, надо будет к акке присмотреться

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

А то пока велосипед на мейлбоксах

С другой стороны, у меня сплошные синглтоны по сути

Поэтому акторы надо порождать специфичные

С шаред стейтом

акторы с шаред стейтом? это что такое?

это какие-то неправильные акторы

Ну у меня сценария многопользовательского нет

Всегда одна сессия

Есть пользовательский контекст, который надо заполнять. Синглтон акторы есть?

Ну конечно

Это хорошо

актор это просто очень хитрый таск, с которым можно общаться

Это при создании актора задается?

Ну конечно это не так), но аналогию такую можно провести

В акке акторы можно через DI создавать, с полным фаршем

А как в f#?

там это называется Props. Т.е. реквизит актора

Хмм

тут есть проблема небольшая с F# акторами. в F# акке акторы создаются с хитрым типом, который DI не распознаётся, потому что ты по сути лямбду создаёшь. А если идти ООП-way, то ты делаешь класс, который наследует Actor и поэтому можешь к этому классу привязываться и создавать его через DI

ООП не хочу

В свое время находился

но в ФП DI вообще по-другому работает - через каррирование

Ну это понятно

Интересует вопрос в применении к akka.fsharp, например

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

ну как бы на небольших проектах норм. Я огромные проекты на F# акке не писал, хз. большой проект на акке у меня был на C#. Это я только потом узнал о F#, переписывать с теми крохотными знаниями никак нельзя было.

Т.е. мейлбокс поднялся, апи я могу плодить сколько угодно инстансов

не понял, какое апи)

Обертка для post etc

ааа

Чтобы не писать постоянно box.Post

Ну в акке это решается конфигом для актора. указываешь там динамическое скалирование и в ус не дуешь