-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Zend\Db transaction api unification #5001
Zend\Db transaction api unification #5001
Conversation
/** | ||
* Disconnect | ||
* | ||
* @return Connection |
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.
@return self
Ok, gonna fix that, thanks! |
Done |
@samsonasik should be ok/compliant if you want to merge. |
👍 I have no access for that :D |
@ralphschindler you'll want to review this one. |
*/ | ||
public function beginTransaction() | ||
{ | ||
// TODO: Implement beginTransaction() method. | ||
|
||
return $this; |
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.
Should this methods throw a BadMethodCallException
until implement the code?
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.
Talked about that with @weierophinney @zendcon today, would be a BC break. So, I propose a first "non breaking" PR followed by another with these fixes.
Hello @Maks3w, just let me know for your BadMethodCallException suggestion, since there were no exception there, I didn't want to change this for BC. |
if (!$this->inTransaction) { | ||
return; | ||
if (!$this->isConnected()) { | ||
throw new Exception\RuntimeException('Must be connected before you can rollback'); |
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.
These exceptions are a BC break and a break in the Interface contract
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.
@Maks3w In fact, depending on the adapter your are looking at, some throwed before my unification, other don't, since this is an adapter pattern, I think that adapters should work the same way. I agree for the BC break, but shouldn't we unify the way these adapters work ?
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.
I don't like the idea of throw exceptions in rollback
By the moment undo this because is not related with the content of the PR. If u want add a new PR later unifying the behavior of this method.
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.
Hello @Maks3w
- I don't get your point, my PR title is "Zend\Db transaction api unification", some of the adapters and not the least (pdo, mysqli, oci8) already throw in rollback which is a part of the transaction system, it seems to me that an unification should make them work the same way.
- If you don't like the throw in rollback, we also could remove it from the three most used adapters, but I think this is far beyond my PR in term of BC break.
- I don't refuse to rollback this change, I just want to be sure you get the entire point.
- If this is only a BC problem, I can make a separate PR for the rollback unification.
- Let me know
Hello @weierophinney, @Maks3w, @ralphschindler, after our ZendCon talk I fixed the points we discussed. Let me know if something is missing for you. |
|
||
use Zend\Db\Adapter\Profiler; | ||
|
||
abstract class AbstractConnection implements ConnectionInterface, Profiler\ProfilerAwareInterface |
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.
I'm sure there will be developers that will disagree with me and who's frame of reference is to always use inheritance even for trivial things, but this abstraction seems unnecessary to me. The guts of this class do nothing algorithmically interesting and since that is the case, I see little need to introduce a base type that all driver connection classes inherit from.
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.
As I told before, this abstract was a basis for another PR, so, I'm going to push it either in order to show you my final goal
@ralphschindler Where does this stand in regards to review and milestone? |
@corentin-larose Can you rebase off of latest develop for me, please? Personally, I'm on board with creating an abstract implementation -- it's less code for us to maintain over the long run, and it clearly provides benefits with regards to unification of behaviors (which is the goal of a DBAL as far as I'm concerned). I think we can merge this for 2.4. |
@corentin-larose this PR needs a rebase |
I have to review once again this is only a tmp commit |
Should be ok for 2.4 |
… `Zend\Db\Adapter\Driver\IbmDb2\Connection`
… `Zend\Db\Adapter\Driver\Mysqli\Connection`
… `Zend\Db\Adapter\Driver\Oci8\Connection`
… `Zend\Db\Adapter\Driver\Pdo\Connection`
… `Zend\Db\Adapter\Driver\Pgsql\Connection`
… `Zend\Db\Adapter\Driver\Sqlsrv\Connection`
Manually merged, thanks :-) |
@corentin-larose please note that I had to remove some commits/squash them due to the rebase not being handled cleanly upfront, so no panic if the commit message is not the original one. |
Hmm this is what happens when letting a PR hanging around for 18 months :D, Went back an dforth from dev to master, conflicts and so... |
@corentin-larose no big deal, I just filtered out the correct commits :-) |
This work is an introduction to another PR to come.