И ты представляешь сколько у них там ВЕРСИЙ доменных событий накопилось, которые надо поддерживать

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

ну, для этого стриминговая прослойка и нужна

про дата лейк кстати тру

Это как поддерживать android приложение, где хранятся все 50 версий миграций sqlite db - нафиг так жить.

Так это любое приложение, которому несколько лет. Если оно активно развивается, конечно.

как это видит бизнес: Data lake

что там на самом деле: залупа из кафки и хадупа

ору

Кстати, видел в новом описании SQLiteOpenHelper onDowngrade. А в каких случаях это вообще может быть нужно. Это если приложение бэкапается?

Или теперь можно версию будет вниз крутить, и будет дергаться этот коллбэк?

Это давно такое.
В библиотеке уместно, например.

Я очень долго сидел на очень старых appcompatах :)

> Added in API level 11

интересно

Неужели упустил.. Ладно, спасибо в любом случае, узнал что-то новое для себя

Вот и в частности по этому я не люблю "толстые клиенты" - они фрагментируют source of truth

Помнится в каком-то google приложение из aosp - видел как они в SqliteOpenHelper дропали базу если она была старше N версии назад. И при этом они могу просто восстановить стейт с сервера.

===

И по этому я люблю сервера, тк там в идеале можно храниться только одну версию миграций.
НО это все обламывается в event-sourcing с НЕ-стираемыми логами.

Надо просто сразу проектировать базу на 10 лет вперёд 🌝

Есть идея получше:

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

В идеале распределённый и на базе блокчейна 😈

ну вот без последней тупой хуйни — эрланг же

Так-то всё есть, хоть в андроиде, хоть на десктопе.
Только никогда ж не знаешь, когда именно обнова доставится.