Наследоваться от нативных классов (с соблюдением LSP) - yea or nay?

[Фанат]

Никаких проблем такое сделать. И ты слишком многое полагаешь на query builder. Выбор соединения все равно должен быть на более высоком уровне.

А как примерно?
Ну в более традиционном варианте - запись намастер, чтение со слейвов?

 

[флоппик]

А как примерно?
Ну в более традиционном варианте - запись намастер, чтение со слейвов?

Ларавель это умеет из коробки версии еще с 4.2 уже лет 5 как: https://laravel.com/docs/4.2/database#read-write-connections

Model::on($connection)->...

где $connection - имя соединения из конфигурации, где можно указать два хоста - один для чтения, другой для записи. Можно два хоста указать в дефолтной конфигурации тоже. Например, у нас обычно в дефолтном соединении всегда реплика чтения указана для админки,
но есть второй коннекшн с именем reports, который смотрит на другую реплику, и мы там просто делаем

 SomeReport::on('reports')->fetch() ...

Можно и явно переключить коннекшн, сменив соединение прямо у капсулы.

 

[Adelf]

Ларавель это умеет из коробки версии еще с 4.2 уже лет 5 как: https://laravel.com/docs/4.2/database#read-write-connections

Только она тупо все селекты на слейв направит, а запись на мастер. А для избежания использования старых данных для записи, надо ВСЕ запросы на мастер слать, когда хотим писать данные, поэтому там надо осторожнее. Но вообще да, это проще с идеологической точки зрения, чем то, о чем Гриша говорит. Там придётся некрасивые условия прописывать и коннекшен нужный для определенного запроса вычислять.

 

[флоппик]

Только она тупо все селекты на слейв направит, а запись на мастер. А для избежания использования старых данных для записи, надо ВСЕ запросы на мастер слать, когда хотим писать данные

Я это решаю просто немного в другом месте: я нарезал на микросервисы, когда еще это не было модным, и те места, которые пишут в базу активно, вообще не имеют в коннекшне реплики.

 

[Adelf]

Я это решаю просто немного в другом месте: я нарезал на микросервисы, когда еще это не было модным, и те места, которые пишут в базу активно, вообще не имеют в коннекшне реплики.

Взрослый подход) теперь я знаю две конторы, которые так делают)

 

[флоппик]

Только она тупо все селекты на слейв направит, а запись на мастер. А для избежания использования старых данных для записи, надо ВСЕ запросы на мастер слать, когда хотим писать данные, поэтому там надо осторожнее.

Опять таки, это нельзя решить автоматически, потому-что никакой фреймворк не определит критичность чтения данных для инсерта сам. Но очень легко - с именованными коннекшнами на уровне приложения:

Model::on('master')->get()->update()...

 

[флоппик]

Взрослый подход) теперь я знаю две конторы, которые так делают)

дяденька, я ж ненастоящий сварщик

 

[WMix]

я конечно понимаю что это не меняет проблему в целом, что слейв не всегда догоняет и кроме как притормозить пользователя сообщением о удачной записи или повторной попыткой чтения это не решить, но если я понимаю о чем вы говорите, то надо тупо в команды (весь UoW) инжектить мастера а в запросы что осталось.

 

[fixxxer]

и srp

бугага

неудачный пример

ну уж я пытаюсь на примере пдо объяснить, раз о ней речь, так-то она сама по себе неудачный пример. В целом мысль в том, что наследование нужно для изменения реализации контракта, а не для изменения (в т.ч. расширения) самого контракта.

 

[grigori]

я пример просто придумал по памяти о том, чем мы с Фанатом занимались лет 10 назад

может быть, при объяснении LSP не стоит рассказывать про service discovery и галеру с почти-консистентной master-master репликацией?