feat(core): allow forcing write connection via forceWriteConnection

[oliversalzburg]

This allows to bypass replica read attempts through the FindOptions, by setting the forceWriteConnection flag.

The intent is to allow users to force reads onto a master, if the user assumes that an entity has not been replicated yet.

[codecov-commenter]

Codecov Report

Merging #2838 (bcc35b7) into master (1584850) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master     #2838   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          194       194           
  Lines        11734     11734           
  Branches      2700      2701    +1     
=========================================
  Hits         11734     11734           

Impacted Files	Coverage Δ
packages/core/src/drivers/IDatabaseDriver.ts	100.00% <ø> (ø)
packages/knex/src/AbstractSqlDriver.ts	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1584850...bcc35b7. Read the comment docs.

[B4nan]

please dont rebase after you get a review, so we maintain the history

[oliversalzburg]

Are the commits ultimately squashed before merging or does every single commit actually have to make sense?

[B4nan]

Yes, only one commit will go to master and the commit message is based on the PR title (and I can override it when merging).

[oliversalzburg]

Understood. I'll try keep better care in the future. I just had a little fight with commitlint and figured I'd quickly amend the commit.

[B4nan]

Yeah not a big deal for such a small PR, but I started to say this out load when I see it, otherwise things never change :]

[asiFarran]

@B4nan @oliversalzburg, in our application the vast majority of queries should run against the master in order to support immediate-read-after-write scenarios, but we do want to use read-replicas for a few specific use-cases (e.g. customer search or analytics queries).

Using the pattern above we'd have to add forceWriteConnection : true to almost all queries which is .... you get it.

I would like to propose the following (more generic) pattern:

1. Add a useReadReplicasByDefault?: boolean to Configuration. This defaults to true so no breaking change and existing behavior is maintained.
2. Replace forceWriteConnection on FindOptions with a useConnection?: 'read' | 'write' property that lets the developer be specific in both directions
3. Use both the configurable default and the optional explicit setting to choose the connection.

This way the connection resolution strategy is completely configurable and can support all scenarios.

Does this sound reasonable to you ? I'm happy to open a PR for it

[B4nan]

Sounds good to me, PR welcome. Given this PR is not yet shipped in stable, I don't mind replacing the newly added forceWriteConnection with useConnection.

[oliversalzburg]

Awesome change btw :)