Так вышло. Протащить слом обратной совместимости 2.0.14 специально не планировали. Именно этот кейс не рассматривали, хотя надо было...
Фича в master было смёржена прилично заранее, мы просили всех проверить master за несколько недель до релиза и получили десяток подтверждений от довольно сложных проектов, что всё нормально.
"Рукавица" зачастую лучше. У "перчатки" внезапно может оказаться слишком много вариантов её конфигурации и логика конфигурирования полезет вон из репозитория.
Нужно будет рыскать по всем репозиториям, да. Это лучше, чем вообще везде.
Как по мне, пример с заменой СУБД — это один из самых плохих примеров потому как в нём не ясно и спорно всё от и до. Вот пример с отсылкой почты или SMS прост, понятен, мало затратен и имеет смысл в подавляющем большинстве случаев.
Имею ввиду не абстрагировать внутренности метода репозитория никак. То есть использовать там SQL или пользоваться простой готовой обёрткой. Не пытаться сделать аналог DQL или HQL, стараясь абстрагировать специфичные фичи PostgreSQL на низком уровне.
А не достаточно ли нам в этом случае репозиториев? Да, поправить, возможно, придётся не в одном месте, а в 10-20, но это не так затратно, как разработка хорошего слоя абстракции реляционной базы (в рамках одного проекта это не выглядит реалистичным в принципе).
Тоже есть отличия, но да. Тут уже попытка не будет столь болезненной, если не очень сильно отходить от SQL99.
Смотря что абстрагировать. Взять те же СУБД. Подход с репозиториями верный, но не самый быстрый. Ну, допустим, сделаем.
В реализации репозиториев завязываться на конкретную СУБД по полной и фигачить внутри SQL? А если заменить надо будет через 10 лет… хммм… начинаем смотреть на PostgreSQL и MySQL. Понимаем что мало того, что придётся прижаться и юзать SQL99 и выкинуть половину крутых фич конкретной базы сразу (и это верно для большинства готовых data mapper-ов и AR), так ещё и не совсем тривиальные обёртки написать для типов данных, JSON и так далее.
Итого время на реализацию такой обёртки составляет треть от времени реализации начальной версии проекта… а может всё-таки зафиксировать что у нас будет всегда PostgreSQL и не страдать фигнёй?
Похоже на то, но вообще это одна контора же, ThoughtWorks. Они зарабатывают на консалтинге и им нужно было чтобы старый добрый cohesion/coupling стал новым модным SOLID.
Так вышло. Протащить слом обратной совместимости 2.0.14 специально не планировали. Именно этот кейс не рассматривали, хотя надо было...
Фича в master было смёржена прилично заранее, мы просили всех проверить master за несколько недель до релиза и получили десяток подтверждений от довольно сложных проектов, что всё нормально.
Ждать чаще. Релизы у нас никогда не были раз в четыре года.
Для тех, кто уже успел JSON использовать — вполне вероятно. Мы не специально...
Так это она и есть в лайт-виде. Это будет не 1.1 → 2.0 когда надо переписать всё, но и не минорный релиз, который можно просто накатить.
Идеи посещали всякие. И эта тоже. В 2.1 не планируется. REST не победит для определённых задач никогда. И не должен.
Можно и добавить. issue создайте.
Стабильность — это хорошо, но 2.0 уже 4 года. Пора.
Уже делаем. В 2.0 всё что нужно помечается как
@deprecated, пишется попутно UPGRADE. Ну и это не 1.1 → 2.0. Не такие страшные изменения будут.Умные программисты знают, что:
Либо никак, либо шардировать так, чтобы связанные записи были всегда на одном шарде.
В плохой понимают только S и забывают про Cohesion. Лучше бы лапшу писали. Рефакторить её проще...
"Рукавица" зачастую лучше. У "перчатки" внезапно может оказаться слишком много вариантов её конфигурации и логика конфигурирования полезет вон из репозитория.
Нужно будет рыскать по всем репозиториям, да. Это лучше, чем вообще везде.
Как по мне, пример с заменой СУБД — это один из самых плохих примеров потому как в нём не ясно и спорно всё от и до. Вот пример с отсылкой почты или SMS прост, понятен, мало затратен и имеет смысл в подавляющем большинстве случаев.
Да, так будет работать и в этом есть смысл, но это далеко не "легко заменить одну базу на другую", как любят приводить в пример.
Имею ввиду не абстрагировать внутренности метода репозитория никак. То есть использовать там SQL или пользоваться простой готовой обёрткой. Не пытаться сделать аналог DQL или HQL, стараясь абстрагировать специфичные фичи PostgreSQL на низком уровне.
Смотря что абстрагировать. Взять те же СУБД. Подход с репозиториями верный, но не самый быстрый. Ну, допустим, сделаем.
В реализации репозиториев завязываться на конкретную СУБД по полной и фигачить внутри SQL? А если заменить надо будет через 10 лет… хммм… начинаем смотреть на PostgreSQL и MySQL. Понимаем что мало того, что придётся прижаться и юзать SQL99 и выкинуть половину крутых фич конкретной базы сразу (и это верно для большинства готовых data mapper-ов и AR), так ещё и не совсем тривиальные обёртки написать для типов данных, JSON и так далее.
Итого время на реализацию такой обёртки составляет треть от времени реализации начальной версии проекта… а может всё-таки зафиксировать что у нас будет всегда PostgreSQL и не страдать фигнёй?
Похоже на то, но вообще это одна контора же, ThoughtWorks. Они зарабатывают на консалтинге и им нужно было чтобы старый добрый cohesion/coupling стал новым модным SOLID.
Да ясно, что clean architecture и всё такое. Это не единственный подход к проектированию.