KD
И снова — зачем эта лишняя работа, если я могу просто дальше использовать базового с новым полем? Не вижу никаких преимуществ.
Size: a a a
2021 April 17
AD
В том что ты можешь контролировать где какая версия юзается и какие новые контракты она имеет
AD
Если юзаешь один класс
AD
Не имеешь этого на уровне типов
KD
У нас в коде всегда используется одна версия.
Не может быть такого, что человек обновил приложение на половину и часть у него со старым классом должна работать, а часть с новым.
Зачем мне заведомо усложнять себе код и логику работая с несколькими версиями данных.
Не может быть такого, что человек обновил приложение на половину и часть у него со старым классом должна работать, а часть с новым.
Зачем мне заведомо усложнять себе код и логику работая с несколькими версиями данных.
AD
Сам себе противоречишь, пишешь что кто то там не обновил
AD
А кто-то там обновил
KD
Не вижу противоречий.
Вижу непонимания о чём я говорю.
Кто-то обновил — у него используются свежие данные, свежий класс.
Кто-то не обновил — у него используются старые данные и старый класс.
Но тот кто обновил не должен работать и со старыми данными и с новыми в приложении, ибо это глупое усложнение.
Вижу непонимания о чём я говорю.
Кто-то обновил — у него используются свежие данные, свежий класс.
Кто-то не обновил — у него используются старые данные и старый класс.
Но тот кто обновил не должен работать и со старыми данными и с новыми в приложении, ибо это глупое усложнение.
AD
Фейспалм
Kd
а чего не работать с делегатом List<Pair<String, Any>> ?
типа user.birthday = list.firstOrNull( it.first == 'birtday' )
типа user.birthday = list.firstOrNull( it.first == 'birtday' )
KD
Ну так это и есть +\- первый вариант о котором я говорил в самом начале.
Kd
совместимость и вперед и назад, а key/value в такой базе хранить милое дело
KD
Но при серьёзных изменениях схемы (или частых) это превратится в жуткую неподдерживаемую лапшу кода, как мне кажется.
Kd
серьезные изменения схемы хранения данных в виде key/value - какие же они могут быть интересно? )))
Kd
никакие
KD
Любые?
Класс может чуть ли не полностью переделаться и с этим тоже бывает нужно жить.
+ всё ещё есть вариант с частыми изменениями.
Здесь добавили поле, здесь убрали, здесь переименовали, здесь изменили тип. Обычная ситуация.
И весь код будет состоять из одних проверок.
Класс может чуть ли не полностью переделаться и с этим тоже бывает нужно жить.
+ всё ещё есть вариант с частыми изменениями.
Здесь добавили поле, здесь убрали, здесь переименовали, здесь изменили тип. Обычная ситуация.
И весь код будет состоять из одних проверок.
Kd
этот код заточён в датасорсе
KD
А код в датасорсе не должен быть читаемым и поддерживаемым?
Kd
должен, но это не значит что ты можешь избавиться от if