юзера и без oauth может захотеть создать

а иногда более одного имейла привязать

сложный бизнес-кейс, однако, нужно выдумывать оригинальное техническое решение

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

сложный бизнес-кейс, однако, нужно выдумывать оригинальное техническое решение

обычнейший бизнес-кейз

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

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

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

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

как понять, что он наступил?

я подумал. На счет саги вчера наврал - это не распределенная транзакция - это описание бизнес процесса, который применяется частично, и для системы в целом, не является атомарной операцией. Соотвественно относительно себя может привести систему в какой то момент к неконсистетному состоянию, (т. е. например создаст пользователя в одном агрегате, но не создаст в другом). Но за то через какое-то время все таки доделает свои части бизнес процесса (дорегистрирует пользователя в другом агрегате ну или откатит изменения в первом) и все будет хорошо. как я понимаю решение за которое топит олег - это например батч в кассандру в несколько таблиц(Пользователи, Имейлы и тд) как легковесные транзакции - лично мне нравится я так и не нашел докладов или статей от грега про саги или распределенные транзакции, но вроде как он и не говорит что "вот везде используйте es" он говорит "нужно построить отчет как sql - ну выгрузи данные в sql и построй там отчет " так что если тут ставится задача стронг консистенси для миллиона пользователей у которых есть миллион идентификаторов можно и не упираться, а сделать через какой нибудь отдельный консистентый сервис можно сделать через сагу - но саги все равно придется отдавать на откуп хотябы техподдержки можно сделать просто два независимых агрегата и говорить пользователю - типа имейл мы твой приняли, все ок, а вот username поменяй - но это бизнес может послать вас(а может и не послать) короче cqrs/es это больше конь в вакууме чем конкретное решение - это просто идея - она не может ответить на вопрос "а как вот мне миллиард пользователей держать в консистетном состоянии" - этим занимаются другие системы и другие подходы кстати агрегаты это не из cqrs/es это частное решение притянутое из ddd, которое решает проблему маленьких быстрых консистентных островков - заметьте в акка персистенс - нету PersistentAggregate

как понять, что он наступил?

да некоего consistencyTimeoutа будет достаточно, в течение которого агрегат не заснет и будет принимать запросы

да некоего consistencyTimeoutа будет достаточно, в течение которого агрегат не заснет и будет принимать запросы

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

В общем, основная идея на которую я сагрился в том, что мы каким-то хорошо известным способом можем поддерживать строгую целостность в CQRS при самой разнообразной эволюции логики. И если мы пришли к тому, что это как минимум неочевидно и требует проработки для каждого отдельного случая, я просто вернусь к своему замечанию о том, что авторизация - это та тема, где нам нужно иметь консистенси не повсюду, но в каком-то хотя бы самом ядре, учитывая что оно обязательно потом будет связано с биллингом, секьюрити и пр. Поэтому для мысленных игр с эвентсорсингом стот взять какую-то менее ответственную область. Какие-нибудь посты и комменты, мессаджи и лайки, витрину или корзину

Ну или если ОП сознательно принимает эвенчуал в своей авторизации, у меня тоже нечего добавить

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

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

Можно вопрос интимного характера? Вы своим интимным нутром ощущаете, что можно заранее сформулировать все требования к юзерстораджу?

Можно вопрос интимного характера? Вы своим интимным нутром ощущаете, что можно заранее сформулировать все требования к юзерстораджу?

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

я настолько морально готов к такому дерьму, что даже не бомбит)

В общем, основная идея на которую я сагрился в том, что мы каким-то хорошо известным способом можем поддерживать строгую целостность в CQRS при самой разнообразной эволюции логики. И если мы пришли к тому, что это как минимум неочевидно и требует проработки для каждого отдельного случая, я просто вернусь к своему замечанию о том, что авторизация - это та тема, где нам нужно иметь консистенси не повсюду, но в каком-то хотя бы самом ядре, учитывая что оно обязательно потом будет связано с биллингом, секьюрити и пр. Поэтому для мысленных игр с эвентсорсингом стот взять какую-то менее ответственную область. Какие-нибудь посты и комменты, мессаджи и лайки, витрину или корзину

+

лол в чате хаскеллистов маленько скалку обсирают, кеек

лол в чате хаскеллистов маленько скалку обсирают, кеек

да мы ее и здесь частенько обсираем.

да там затирают про какой-то процедурный код в определениях

лол в чате хаскеллистов маленько скалку обсирают, кеек

В гиттере?

да там затирают про какой-то процедурный код в определениях

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

Слава богу, что не Хаскель)

В гиттере?

телега

Где-то ещё есть скала чат?

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

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

захожу к хаскеллистам, они превозмогают синтаксис

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

/toxic )

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

токсичненько Алексей, спасибо, что хоть не нубасом назвал

токсичненько Алексей, спасибо, что хоть не нубасом назвал

а что сразу на свой счет то? ?

Да может он не про тебя)

Он просто свои статистические наблюдения привёл)

лол в чате хаскеллистов маленько скалку обсирают, кеек

не нашёл

Он хотел написать хаскелистов

Процедурный код в определениях попахивает Скалкой. За ним - туда

@odomontois

Процедурный код в определениях попахивает Скалкой. За ним - туда

не вижу обсирания - тут голая правда

ну тип посылать людей с одного языка на другой - ну такое, не?)

посмотрите на akka GraphDSL

посмотрите на akka GraphDSL

можно на ты, Олег, если не против.

все лучшие придут в скалу

а эти так и будут сидеть без процедурного кода в определениях

можно на ты, Олег, если не против.

против

В голос

/toxic

я подумал. На счет саги вчера наврал - это не распределенная транзакция - это описание бизнес процесса, который применяется частично, и для системы в целом, не является атомарной операцией. Соотвественно относительно себя может привести систему в какой то момент к неконсистетному состоянию, (т. е. например создаст пользователя в одном агрегате, но не создаст в другом). Но за то через какое-то время все таки доделает свои части бизнес процесса (дорегистрирует пользователя в другом агрегате ну или откатит изменения в первом) и все будет хорошо. как я понимаю решение за которое топит олег - это например батч в кассандру в несколько таблиц(Пользователи, Имейлы и тд) как легковесные транзакции - лично мне нравится я так и не нашел докладов или статей от грега про саги или распределенные транзакции, но вроде как он и не говорит что "вот везде используйте es" он говорит "нужно построить отчет как sql - ну выгрузи данные в sql и построй там отчет " так что если тут ставится задача стронг консистенси для миллиона пользователей у которых есть миллион идентификаторов можно и не упираться, а сделать через какой нибудь отдельный консистентый сервис можно сделать через сагу - но саги все равно придется отдавать на откуп хотябы техподдержки можно сделать просто два независимых агрегата и говорить пользователю - типа имейл мы твой приняли, все ок, а вот username поменяй - но это бизнес может послать вас(а может и не послать) короче cqrs/es это больше конь в вакууме чем конкретное решение - это просто идея - она не может ответить на вопрос "а как вот мне миллиард пользователей держать в консистетном состоянии" - этим занимаются другие системы и другие подходы кстати агрегаты это не из cqrs/es это частное решение притянутое из ddd, которое решает проблему маленьких быстрых консистентных островков - заметьте в акка персистенс - нету PersistentAggregate

В кассандре же нельзя serial (lightweight transactions) на несколько таблиц делать. На несколько партишнов ключа-то нельзя. Или я не прав, и можно? Очень интересно, если так.

В кассандре же нельзя serial (lightweight transactions) на несколько таблиц делать. На несколько партишнов ключа-то нельзя. Или я не прав, и можно? Очень интересно, если так.

https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlLtwtTransactions.html

https://docs.datastax.com/en/cql/3.1/cql/cql_reference/batch_r.html > In Cassandra 2.0.6 and later, you can batch conditional updates introduced as lightweight transactions in Cassandra 2.0. Only updates made to the same partition can be included in the batch because the underlying Paxos implementation works at the granularity of the partition.

https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlLtwtTransactions.html

@odomontois я не очень понял как это отвечает на мой вопрос, можешь уточнить, если не сложно?

@odomontois я не очень понял как это отвечает на мой вопрос, можешь уточнить, если не сложно?

я ослеп немного, сейчас

Coq (язык формулировки математических теорий и программирования, основанный на зависимых типах, описан в книге «Coq’art: Interactive theorem proving and program development» отчасти использует алгоритм Хиндли — Милнера с определенным количеством эвристик, однако его система типов настолько сложна и мощна, что вывод типов в ней является вычислительно неразрешимой задачей, поэтому очень часто типы приходится указывать вручную.

Coq (язык формулировки математических теорий и программирования, основанный на зависимых типах, описан в книге «Coq’art: Interactive theorem proving and program development» отчасти использует алгоритм Хиндли — Милнера с определенным количеством эвристик, однако его система типов настолько сложна и мощна, что вывод типов в ней является вычислительно неразрешимой задачей, поэтому очень часто типы приходится указывать вручную.

хм, я не очень силён в CS но даже если ты указал тип руками, компилятору же нужно проверить, что ты указал его валидно, т.е. всё равно вывести тип.

Или он поверит, а потом в рантайме упадёт?

мб он не проверяет?

или проверяет только для простых случаев

В кассандре же нельзя serial (lightweight transactions) на несколько таблиц делать. На несколько партишнов ключа-то нельзя. Или я не прав, и можно? Очень интересно, если так.

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

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

атомарный == через serial/paxos? или как-то еще?

через SERIAL, да

через SERIAL, да

Что-то это расходится с моей интерпретацией документации. Пойду попробую.

По идее нельзя писать IF [NOT] EXISTS на несколько партишнов => таблиц, а по-другому LWT на запустишь же?

или проверяет только для простых случаев

до фига он проверяет

в этом вся суть его

ты же там только и делаешь, что типы доказываешь, а не кот котишь

cqlsh:test> CREATE TABLE test.customers ( ... user bigint, ... balance int, ... PRIMARY KEY (user) ... ); cqlsh:test> CREATE TABLE test.purchases ( ... user bigint, ... expense_id bigint, ... amount int, ... PRIMARY KEY (user, expense_id) ... ); cqlsh:test> BEGIN BATCH S; ... INSERT INTO customers (user, balance) VALUES (1, -10) IF NOT EXIST ; ... INSERT INTO purchases (user, expense_id, amount) VALUES (1, 1, 10) ... APPLY BATCH; InvalidRequest: Error from server: code=2200 [Invalid query] message="Batch with conditions cannot span multiple tables"

@odomontois ^

или ты предлагаешь вручную выставлять SERIAL? Но это вроде невозможно.

@odomontois почему у вас так медленно работает сайт? отвечай !

cqlsh:test> CREATE TABLE test.customers ( ... user bigint, ... balance int, ... PRIMARY KEY (user) ... ); cqlsh:test> CREATE TABLE test.purchases ( ... user bigint, ... expense_id bigint, ... amount int, ... PRIMARY KEY (user, expense_id) ... ); cqlsh:test> BEGIN BATCH S; ... INSERT INTO customers (user, balance) VALUES (1, -10) IF NOT EXIST ; ... INSERT INTO purchases (user, expense_id, amount) VALUES (1, 1, 10) ... APPLY BATCH; InvalidRequest: Error from server: code=2200 [Invalid query] message="Batch with conditions cannot span multiple tables"

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

хм, я не очень силён в CS но даже если ты указал тип руками, компилятору же нужно проверить, что ты указал его валидно, т.е. всё равно вывести тип.

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

cqlsh:test> CREATE TABLE test.customers ( ... user bigint, ... balance int, ... PRIMARY KEY (user) ... ); cqlsh:test> CREATE TABLE test.purchases ( ... user bigint, ... expense_id bigint, ... amount int, ... PRIMARY KEY (user, expense_id) ... ); cqlsh:test> BEGIN BATCH S; ... INSERT INTO customers (user, balance) VALUES (1, -10) IF NOT EXIST ; ... INSERT INTO purchases (user, expense_id, amount) VALUES (1, 1, 10) ... APPLY BATCH; InvalidRequest: Error from server: code=2200 [Invalid query] message="Batch with conditions cannot span multiple tables"

я хз с моего дивана все выглядело ок)))

я хз с моего дивана все выглядело ок)))

А я было уже начал радоваться и посыпать голову пеплом, но увы

инференс для завтипов неразрешим да

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

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

По идее нельзя писать IF [NOT] EXISTS на несколько партишнов => таблиц, а по-другому LWT на запустишь же?

нельзя условия на несколько партишнов

но без условий можно

@odomontois как это синтаксически выглядит, можешь привести пример?

потому что насколько я понимаю, единственный способ сделать consistency = SERIAL это использовать IF

потому что насколько я понимаю, единственный способ сделать consistency = SERIAL это использовать IF

да, короч, ты прав во всём

ЙЕЕЕ

гм, надо это заскриншотить и сохранить куда-то, Олег признает, что не прав

он не признает что неправ

он признает что кто то другой прав

не надо передергивать

В sbt если в рутовом сабмодуле какие-то настройки вынести в inThisBuild, они же подтянутся всеми остальными сабмодулями, верно?