Add transaction support #1904
Add transaction support #1904
Conversation
…ployment replica sets or sharded clusters
transaction support create/insert,update,delete,etc operation
Supports infinite-level nested transactions, but outside transaction rollbacks do not affect the commit of inside transactions
```
DB::beginTransaction();
DB::collection('users')->where('name', 'klinson')->update(['age' => 18]);
DB::transaction(function () {
DB::collection('users')->where('name', 'mongodb')->update(['age' => 30]);
});
DB::rollBack();
```
|
@klinson check failed tests in travis build please |
|
@Smolevich Because transaction requires mongodb version V4.0 or more and deployment replica sets or sharded clusters, but your environment doesn't. |
|
@klinson, Not my environment, it is common configuration based on official docker images, you can change if it's needed |
|
@klinson if you work on PR, add 'WIP' to title of PR |
|
@Smolevich I've modified the environment to support it |
|
@jenssegers i prepare Smolevich/demo-mongo-application#9 for demo. It is not finished, but today i finish |
Co-Authored-By: Stas <[email protected]>
|
@klinson do you have plans to add changes for PR? |
|
I will continue to change it |
|
Any news guys? Can you review please @jenssegers ? |
|
review please @Smolevich |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
As commented, I would remove hard-coding of transaction options as well as the ability to start multiple transactions in parallel.
In addition to that, this PR is missing the implementation of the DB::transaction() helper. While the default logic would work, the MongoDB\with_transaction function shipped with the MongoDB driver contains logic designed to avoid re-invoking the callback for errors that only require a second commit command. The retry logic of that function is a little different from the default logic, but that difference should not have any negative effects.
| 'readPreference' => new ReadPreference(ReadPreference::RP_PRIMARY), | ||
| 'writeConcern' => new WriteConcern(1), | ||
| 'readConcern' => new ReadConcern(ReadConcern::LOCAL) |
There was a problem hiding this comment.
I would avoid hardcoding these options this way, especially with the given values. There is no prior art for passing options (as most methods in the query builder don't accept any options), but an optional $transactionOptions parameter for this method would be more sensible than hardcoding these values here.
| public function beginTransaction() | ||
| { | ||
| $this->session_key = uniqid(); | ||
| $this->sessions[$this->session_key] = $this->connection->startSession(); |
There was a problem hiding this comment.
Given that the session from the connection instance is applied automatically to all operations sent through the query builder, I'd refrain from starting multiple sessions. Looking at the transaction logic used for PDO, the first call to beginTransaction will start a new transaction, while subsequent only create save points (or no-op if those are not supported). I generally believe this to be a better alternative that should be used instead.
|
Any update on this? |
|
I have an almost-done version of this locally and will aim to have a new pull request up in the coming days. Stay tuned... |
Thank you @alcaeus |
|
Closed in favor of #2465, thank you for your work! |
requires mongodb version V4.0 or more and deployment replica sets or sharded clusters
transaction support create/insert,update,delete,etc operation
Supports infinite-level nested transactions, but outside transaction rollbacks do not affect the commit of inside transactions