Feature #6131
closedWhy Transaction is not movable?
0%
Description
In my project I have Entities. Each entity has a Model. Each Model is linked to a database (at the moment only one), encapsulates a Wt::Dbo::Session and the logic to do the queries. To the outside world the Model offers functions like Load/Store(Entity).
To be able to make custom/grouped queries and need a common transaction for them. Instead of doing Wt::Dbo::Session& Model::GetSession() (thus everybody will have direct access to session) I want to make:
Wt::Dbo::Transaction Model::CreateTransaction() {
return Wt::Dbo::Transaction{*mEncapsulatedSession.get()};
}
Then I will be able to do:
{
Wt::Dbo::Transaction transaction = model.CreateTransaction();
model.Store(entity1, transaction); // an overloaded Store() that accepts Wt::Dbo::Transaction& as second parameter and doesn't create a new transaction
model.Store(entity2, transaction);
}
Can you make Transaction movable? I don't see a reason why it's not movable.
Updated by Roel Standaert over 6 years ago
It was explicitly made not movable because there was no proper implementation for it, and there is also not a proper moved-from state.
You could of course return a std::unique_ptr to a transaction, though, or put it into some other object that wraps it.
Updated by Roel Standaert over 6 years ago
I could maybe consider making Transaction objects copyable, though.
Copying a transaction like so:
Wt::Dbo::Transaction t{session};
Wt::Dbo::Transaction t2 = t;
Would then have the same effect as:
Wt::Dbo::Transaction t{session};
Wt::Dbo::Transaction t2{session};
Note that in any case, Transaction has a session() method, so you can always access the underlying Session object.
I've also noticed though that Transaction has a virtual destructor, so it's probably still best not to make Transaction copyable.
Updated by Oleg Artenii over 6 years ago
Note that in any case, Transaction has a session() method, so you can always access the underlying Session object.
Thanks. Then close this issue please.
There is a much more important one https://redmine.emweb.be/issues/6130