-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
Adding TransactionalManagerInterface #443
Adding TransactionalManagerInterface #443
Conversation
9ab91cd
to
d862c27
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
d862c27
to
317aad8
Compare
BaseManager is a base for both doctrineORM and doctirneMOngo. There is transaction in EntityManager so we can add it to BaseEntityManager. |
f9a3940
to
f77639b
Compare
Linter is failing |
841b6b9
to
f0b4fe9
Compare
the phpcs I could run locally, But psalm doesn't work :/, Then I do not know it it was fixed! |
34b9b09
to
b3c97ba
Compare
I added the return type for tests |
b3c97ba
to
6ff740c
Compare
6ff740c
to
07195a0
Compare
sorry for keeping you running the pipelines :( |
let me know if it's missing something! |
And what was the decision 👀 |
try { | ||
$this->getEntityManager()->commit(); | ||
} catch (\Throwable $exception) { | ||
throw new TransactionException($exception->getMessage(), (int) $exception->getCode(), $exception); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have mixed feelings about wrapping in our own exception. What are the benefits?
I have one con, people used to try catch normal doctrine exception for commit, will have to think about this new exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To solve this we could extends from doctrine exception!
But I would say that usually will be used Throwable
or DoctrineException
into the code, I guess this TransactionException
won't be used!
IMO we could remove this try/catch
and let Doctrine exception raise!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People are using commit on the Sonata EntityManager, not the doctrine one. So it would be weird to have doctrine exception.
Also, when you are working with the interface, ho do you know if it will be orm exception, mongo exception, something else exception etc.
The over option is to just use a throwable annotation... I thought it could be good to prefer a domain exception
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, when you are working with the interface, ho do you know if it will be orm exception, mongo exception, something else exception etc.
In this case I'll know, because we are implementing only for EntityManager, mongo entity doesn't use this interface!
People are using commit on the Sonata EntityManager, not the doctrine one. So it would be weird to have doctrine exception.
Yeah I got your point, I agree that it's a bit strange implements a Sonata interface and throw an exception of other dependency!
well we have pros and cons 😄
But if we going to use a custom Exception I guess we should extends of DoctrineException 👀
Note: But looking for the benefit side, I would say it won't be too helpful, usually the catch will have only DoctrineException
to catch some errors!
and maybe it will be a BC because for now we are throwing DoctrineException and if we return CustomException it won't go into the caches that already exist catching Doctrine
stuffs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case I'll know, because we are implementing only for EntityManager, mongo entity doesn't use this interface!
When I use this interface, I'm not supposed to know which one are implementing it and which one don't.
Maybe ORM will stop transaction one day. Maybe Mongo will start one day.
The goal is too decouple from the implementation.
But if we going to use a custom Exception I guess we should extends of DoctrineException 👀
I'm not sure you have something like a BaseDoctrineException, used by both ORM and Mongo.
and maybe it will be a BC because for now we are throwing DoctrineException and if we return CustomException it won't go into the caches that already exist catching Doctrine stuffs.
It's not a BC break since we're adding a method/interface.
If you use ->getEntityManager->commit
you have the ORM exception
If you use ->commit
you have the Sonata exception
I think I found at least another case on SonataMediaBundle where this could be useful. |
Can you explain what you have in mind ? |
Nothing, I have searched where do we use transactions and are only on PageBundle |
Subject
I am targeting this branch, because it has the support for the php 7.4 version.
Related with sonata-project/SonataPageBundle#1550.
Changelog