А как примерно?
Ну в более традиционном варианте - запись намастер, чтение со слейвов?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Наследоваться от нативных классов (с соблюдением LSP) - yea or nay?
- Автор темы Фанат
- Дата начала
Ну в более традиционном варианте - запись намастер, чтение со слейвов?
Ларавель это умеет из коробки версии еще с 4.2 уже лет 5 как: https://laravel.com/docs/4.2/database#read-write-connections
Код:
Model::on($connection)->...но есть второй коннекшн с именем reports, который смотрит на другую реплику, и мы там просто делаем
Код:
SomeReport::on('reports')->fetch() ...
Только она тупо все селекты на слейв направит, а запись на мастер. А для избежания использования старых данных для записи, надо ВСЕ запросы на мастер слать, когда хотим писать данные, поэтому там надо осторожнее. Но вообще да, это проще с идеологической точки зрения, чем то, о чем Гриша говорит. Там придётся некрасивые условия прописывать и коннекшен нужный для определенного запроса вычислять.
Я это решаю просто немного в другом месте: я нарезал на микросервисы, когда еще это не было модным, и те места, которые пишут в базу активно, вообще не имеют в коннекшне реплики.
Взрослый подход) теперь я знаю две конторы, которые так делают)
Опять таки, это нельзя решить автоматически, потому-что никакой фреймворк не определит критичность чтения данных для инсерта сам. Но очень легко - с именованными коннекшнами на уровне приложения:
PHP:
Model::on('master')->get()->update()...дяденька, я ж ненастоящий сварщик
я конечно понимаю что это не меняет проблему в целом, что слейв не всегда догоняет и кроме как притормозить пользователя сообщением о удачной записи или повторной попыткой чтения это не решить, но если я понимаю о чем вы говорите, то надо тупо в команды (весь UoW) инжектить мастера а в запросы что осталось.
Последнее редактирование:
бугагаи srp
ну уж я пытаюсь на примере пдо объяснить, раз о ней речь, так-то она сама по себе неудачный пример. В целом мысль в том, что наследование нужно для изменения реализации контракта, а не для изменения (в т.ч. расширения) самого контракта.
