-
|
Is there a sensible pattern for using this with EFCore and databases, where the database itself is the candidate change?
Naively, this would entail running always running all queries on both databases and checking that the results are the same and that the query time is comparable. But that would appear to involve also refactoring the whole code-base to carry around doubled up values.
Due to a variety of factors, including race conditions, we can't be sure that both DBs return the same ID for Joe. This means that we need to run the CRUD statements against both databases, and then ensure that query parameters to each DB only ever use IDs generated by the DB being queried... |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
I’d question the need to test the database itself as a candidate! If you’re migrating then migrate; I’d recommend the repository pattern for this sort of stuff. If you really wanted to experiment between 2 data sources then you will need to create the Id yourself & send that to the 2 data sources & not have them generate it automatically for you. |
Beta Was this translation helpful? Give feedback.
I’d question the need to test the database itself as a candidate! If you’re migrating then migrate; I’d recommend the repository pattern for this sort of stuff.
If you really wanted to experiment between 2 data sources then you will need to create the Id yourself & send that to the 2 data sources & not have them generate it automatically for you.