-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deserialization should happen inside a transaction #38442
Conversation
|
8222027
to
4e482b0
Compare
I've just got some non functional concerns / structural questions. The first thing I noticed was a disparity in the level of abstraction where the transaction was started - one at the top of the stack in a handler, and the other a few calls deep into the call stack for command. Why have we not pushed it further down in the former or placed it higher up in the latter? My preference is to push it as low down the stack as necessary - it's a low level detail and in generally we'll be looking back up the stack from low level database code or exceptions to check if we're in a transaction. In the lower level case here, we're putting it around code to (1) set a caching scope, (2) load the yaml file, and then (3) load it. As far as I can see the former two do not interact with the database, and we can our transaction block down into Even if we need it slightly higher up the stack I'd rather stick it in a function that takes a filepath and ingestion options, and DRYs up those three steps. |
agree with Chris, this should be done within serdes somehow |
I had some doubts about having |
4e482b0
to
bff3f39
Compare
@crisptrutski @qnkhuat re-review please :) |
Deserialization can leave a target database in a broken state if an error happens. Wrapping it into transaction will prevent this.
Resolves #20632.