Size: a a a

Clojure — русскоговорящее сообщество

2020 September 02

MB

Mikhail Borisov in Clojure — русскоговорящее сообщество
Anton Chikin
Они могли быть независимыми на момент написания, но потом подъехали новые требования и хорошо бы их оставить независимыми но иметь возможность запустить последовательно.
Последовательно в смысле в одном потоке, но без сохранения отношения "первый/второй"?
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Mikhail Borisov
Последовательно в смысле в одном потоке, но без сохранения отношения "первый/второй"?
в смысле как раз с сохранением порядка
источник

MB

Mikhail Borisov in Clojure — русскоговорящее сообщество
Если порядок есть, то в каком смысле они независимые?
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Сейчас у dispatch-n и у нескольких dispatch порядок не гарантирован
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Mikhail Borisov
Если порядок есть, то в каком смысле они независимые?
Порядок есть только в данном конкретном случае
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Т.е. нет такого что “после А мы всегда хотим вызывать B”
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
А скорее “в данном случае по бизнес логике после A нужно вызвать B”
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Сейчас в re-frame возможен только первый вариант
источник

MB

Mikhail Borisov in Clojure — русскоговорящее сообщество
Т.е. это только внутри батчей должно работать? Типа сортируем, как нам кажется логичным?
источник

MB

Mikhail Borisov in Clojure — русскоговорящее сообщество
Честно говоря я вообще не в теме, я так понял речь о том, чтобы I/O диспатчить)
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Нет речь не про io
источник

MB

Mikhail Borisov in Clojure — русскоговорящее сообщество
Anton Chikin
А скорее “в данном случае по бизнес логике после A нужно вызвать B”
И вот это я понял, как идею, что если есть батч из операций, в котором допустим есть чтения и записи, то обычно мы хотим сначала сделать записи, потом прочитать
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Хотя это интересная мысль - например re-frame гарантирует что db эффект выполнится первым. Почему он не гарантирует что io эффекты выполнятся последними?
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Mikhail Borisov
И вот это я понял, как идею, что если есть батч из операций, в котором допустим есть чтения и записи, то обычно мы хотим сначала сделать записи, потом прочитать
Ну это я про свой конкретный кейс рассуждал. В целом там скорее “мы хотим гарантированный порядок операций в батче”
источник

MB

Mikhail Borisov in Clojure — русскоговорящее сообщество
Anton Chikin
Ну это я про свой конкретный кейс рассуждал. В целом там скорее “мы хотим гарантированный порядок операций в батче”
Возможность как-то его задавать? Или чтобы хоть какой-то был?
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
возможность его задавать
источник

RN

Ryzhikov Nikolay in Clojure — русскоговорящее сообщество
те это чистая accidental complexity - мало того что stateful еще и от порядка зависит 😉
источник

RN

Ryzhikov Nikolay in Clojure — русскоговорящее сообщество
в обратном выполнишь - все сломается
источник

RN

Ryzhikov Nikolay in Clojure — русскоговорящее сообщество
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Ryzhikov Nikolay
те это чистая accidental complexity - мало того что stateful еще и от порядка зависит 😉
Ну почему accidental? У нас такие бизнес требования - форму нужно сначала заполнить потом отправить. В обратном порядке не работает 🙂
источник