AP
Я тоже не так давно начал так делать, спасибо @why_oleg. Это реально удобнее.
Size: a a a
2020 December 01
AP
уже получается нельзя 😉
AN
AP
onEach
точно 😉
OY
вообще рекомендуется делать не collect, а
onEach{}.launchIn(scope). В этом случае возвращается Job и когда он закончен, тогда и прекратилосьвсё же это разные вещи для разных юзкейсов)
в данном случае, если надо что-то сделать сразу после collect в том скоупе, где collect был запущен, то финт с launchIn не так полезен
если же надо знать, что collect закончился извне - то другое дело
в данном случае, если надо что-то сделать сразу после collect в том скоупе, где collect был запущен, то финт с launchIn не так полезен
если же надо знать, что collect закончился извне - то другое дело
AN
всё же это разные вещи для разных юзкейсов)
в данном случае, если надо что-то сделать сразу после collect в том скоупе, где collect был запущен, то финт с launchIn не так полезен
если же надо знать, что collect закончился извне - то другое дело
в данном случае, если надо что-то сделать сразу после collect в том скоупе, где collect был запущен, то финт с launchIn не так полезен
если же надо знать, что collect закончился извне - то другое дело
Да, немного разное. Но обычно коллектор в отдельном ланче запускается.
OY
Да, немного разное. Но обычно коллектор в отдельном ланче запускается.
наверно, даже не знаю, it depends всё же
* collect - после него операция выполниться только если не будет ошибки, если надо и когда ошибку - нужен try
* onCompletion - вызовется и при завершении с ошибкой и без и передаст ошибку в lambda, и потом, когда вызовется collect будет та же схема что сверху
* launchIn - запустит в другом scope - и там уже в другом месте можно проверить, завершился с ошибкой или нет и доставать ошибку уже не так прям приятно)
вот
* collect - после него операция выполниться только если не будет ошибки, если надо и когда ошибку - нужен try
* onCompletion - вызовется и при завершении с ошибкой и без и передаст ошибку в lambda, и потом, когда вызовется collect будет та же схема что сверху
* launchIn - запустит в другом scope - и там уже в другом месте можно проверить, завершился с ошибкой или нет и доставать ошибку уже не так прям приятно)
вот
AN
наверно, даже не знаю, it depends всё же
* collect - после него операция выполниться только если не будет ошибки, если надо и когда ошибку - нужен try
* onCompletion - вызовется и при завершении с ошибкой и без и передаст ошибку в lambda, и потом, когда вызовется collect будет та же схема что сверху
* launchIn - запустит в другом scope - и там уже в другом месте можно проверить, завершился с ошибкой или нет и доставать ошибку уже не так прям приятно)
вот
* collect - после него операция выполниться только если не будет ошибки, если надо и когда ошибку - нужен try
* onCompletion - вызовется и при завершении с ошибкой и без и передаст ошибку в lambda, и потом, когда вызовется collect будет та же схема что сверху
* launchIn - запустит в другом scope - и там уже в другом месте можно проверить, завершился с ошибкой или нет и доставать ошибку уже не так прям приятно)
вот
Верно кроме последнего. Если есть Job, то достать ошибку не проблема.
OY
Верно кроме последнего. Если есть Job, то достать ошибку не проблема.
там неудобно отделять, отменили или вылетела ошибка
OY
Верно кроме последнего. Если есть Job, то достать ошибку не проблема.
тем более, единственный способ получить ошибку это либо обернуть в try ensureActive и словить ошибку, либо использовать Job.getCancellationException() - который помечен как internal
AN
Котлин плагин прикатился в EAP
SB
SB
или не ура, не приехало
RI
Да, я обновился (еще вчера), работает нормально. Нужно на EAP канал обновления плагина перейти
SB
Да, я обновился (еще вчера), работает нормально. Нужно на EAP канал обновления плагина перейти
спасибо
ML
Ребят, привет, а кто может в меня покидать ещё вариантами создания схемы данных (для сериализации или sql, например)
по типу того, как сделано в Kuery или Lychee.
Интересует прежде всего варианты того как потом работать с объектами, созданными по этой схеме
по типу того, как сделано в Kuery или Lychee.
Интересует прежде всего варианты того как потом работать с объектами, созданными по этой схеме
ML
Пример того, о чём я говорю:
object Organizations : Table("organizations") {
val id = Column("id")
val name = Column("name")
}
object Organizations : Table("organizations") {
val id = Column("id")
val name = Column("name")
}
OY
Ребят, привет, а кто может в меня покидать ещё вариантами создания схемы данных (для сериализации или sql, например)
по типу того, как сделано в Kuery или Lychee.
Интересует прежде всего варианты того как потом работать с объектами, созданными по этой схеме
по типу того, как сделано в Kuery или Lychee.
Интересует прежде всего варианты того как потом работать с объектами, созданными по этой схеме
Exposed, ktorm
OY
Xodus-dnq
AN
Ребят, привет, а кто может в меня покидать ещё вариантами создания схемы данных (для сериализации или sql, например)
по типу того, как сделано в Kuery или Lychee.
Интересует прежде всего варианты того как потом работать с объектами, созданными по этой схеме
по типу того, как сделано в Kuery или Lychee.
Интересует прежде всего варианты того как потом работать с объектами, созданными по этой схеме
https://github.com/mipt-npm/dataforge-core/blob/master/dataforge-meta/src/commonMain/kotlin/hep/dataforge/meta/Scheme.kt
Самое массовое использование сейчас в plotly.kt. Пример: https://github.com/mipt-npm/plotly.kt/blob/a22ca33c7853b003ab6f83994d52a83a05e6645e/plotlykt-core/src/commonMain/kotlin/kscience/plotly/models/Axis.kt#L42.
Это не совсем для сериализации. Точнее для сериализации в том числе, но основное применение - отслеживание изменений в реальном времени, конфигурирование и дифы.
Самое массовое использование сейчас в plotly.kt. Пример: https://github.com/mipt-npm/plotly.kt/blob/a22ca33c7853b003ab6f83994d52a83a05e6645e/plotlykt-core/src/commonMain/kotlin/kscience/plotly/models/Axis.kt#L42.
Это не совсем для сериализации. Точнее для сериализации в том числе, но основное применение - отслеживание изменений в реальном времени, конфигурирование и дифы.