🇬🇧United Kingdom @matason

Thanks for sorting that out, xurizaemon!

Best,

Chris

Thanks Rohan!

Thanks for doing that, I've made a small comment on the merge request.

Best,

Chris

Apologies, I have reported this to the wrong project, I'll move it.

matason → created an issue.

Hi, I was just trying to update the merge request, I've probably done something wrong - https://git.drupalcode.org/issue/menu_breadcrumb-3392139/-/pipelines/310...

Sorry.

matason → made their first commit to this issue’s fork.

Hi folks,

I've had a look at the patch and it's pretty much the direction I was going in, I'd start work on it locally before checking the issue queue...

Having reached the same point, I started to think about it bit more... regarding SqlContentEntityStorage, I think it could be a good idea to separate out the read operations from the write options.

I'm thinking SqlContentEntityStorage could become a facade with two underlying objects, a reader and a writer. That way, instead of introducing more execution paths to the code in the class "if we're reading, use a replica, if we're writing, use default", we can just pass the database.replica to the reader, safe in the knowledge that it'll get default if no replica's are configured and pass default through to the writer.

Before I go off and attempt to carve this out, I just thought I'd share the idea to see if sounds sensible to anyone else?

Remove the "in the future" nature of the SQLite requirements for Drupal 10.