Статическая типизация вообще с непривычки наверняка очень неудобна. Зато имеет уйму преимуществ. А инструмент себе вы, конечно же, выбираете сами.
Статическая типизация (как минимум exposed от jetbrains) не позволяет работать с неопределенными полями, что в условиях, когда поля в таблице могут динамически меняться, неприемлемо.
Статическая типизация (как минимум exposed от jetbrains) не позволяет работать с неопределенными полями, что в условиях, когда поля в таблице могут динамически меняться, неприемлемо.
я могу сказать неприемлено это когда схема бд меняется без миграций
Я тут немного ворвался и не понял, как динамический тип хранится в РСУБД.
Я имел ввиду что одно поле может внезапность замениться другим. И что мне тогда делать? Лезть в код апи, переписывать его и перезаливать апи? А если завтра оно измениться снова? (делать список полей в отдельном файле - костыль)
Я имел ввиду что одно поле может внезапность замениться другим. И что мне тогда делать? Лезть в код апи, переписывать его и перезаливать апи? А если завтра оно измениться снова? (делать список полей в отдельном файле - костыль)
(Те было у объекта в бд поле STORE_MOSCOW. Завтра поле удалили и добавили STORE_PSKOV)
Я имел ввиду что одно поле может внезапность замениться другим. И что мне тогда делать? Лезть в код апи, переписывать его и перезаливать апи? А если завтра оно измениться снова? (делать список полей в отдельном файле - костыль)
Да, дружище, именно для этого типы и придумали, чтобы избежать целые классы ошибок, вызванные подобными изменениями.
Я имел ввиду что одно поле может внезапность замениться другим. И что мне тогда делать? Лезть в код апи, переписывать его и перезаливать апи? А если завтра оно измениться снова? (делать список полей в отдельном файле - костыль)
Выглядит, как нездоровое проектирование. На кой черт вообще тогда рсубд брать а не монгу какую-нибудь?