Так вышло. Протащить слом обратной совместимости 2.0.14 специально не планировали. Именно этот кейс не рассматривали, хотя надо было...
Фича в master было смёржена прилично заранее, мы просили всех проверить master за несколько недель до релиза и получили десяток подтверждений от довольно сложных проектов, что всё нормально.
"Рукавица" зачастую лучше. У "перчатки" внезапно может оказаться слишком много вариантов её конфигурации и логика конфигурирования полезет вон из репозитория.
Нужно будет рыскать по всем репозиториям, да. Это лучше, чем вообще везде.
Как по мне, пример с заменой СУБД — это один из самых плохих примеров потому как в нём не ясно и спорно всё от и до. Вот пример с отсылкой почты или SMS прост, понятен, мало затратен и имеет смысл в подавляющем большинстве случаев.
Имею ввиду не абстрагировать внутренности метода репозитория никак. То есть использовать там SQL или пользоваться простой готовой обёрткой. Не пытаться сделать аналог DQL или HQL, стараясь абстрагировать специфичные фичи PostgreSQL на низком уровне.
А не достаточно ли нам в этом случае репозиториев? Да, поправить, возможно, придётся не в одном месте, а в 10-20, но это не так затратно, как разработка хорошего слоя абстракции реляционной базы (в рамках одного проекта это не выглядит реалистичным в принципе).
Тоже есть отличия, но да. Тут уже попытка не будет столь болезненной, если не очень сильно отходить от SQL99.
Посоветовались. Сделаем в патч-релизе (будет скоро) возможность выключить.
Горшочек, не вари!
SilverFire что скажешь?
extension-ы, тем не менее, придётся обновлять...
Так вышло. Протащить слом обратной совместимости 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 на низком уровне.