-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Remove hard dependency on PDO #2958
Conversation
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.
Overall, I understand why this is being attempted, but I don't think users will benefit much from it, as most of our users do in fact use PDO, so the rest shouldn't have a problem with keeping it installed.
What I see though, is using bitmasks to define bound parameter types, which is problematic when we consider things like multi-dimensional parameters. This doesn't affect low-level API, but it is one of the pain-points of our API (binding with Connection::PARAM_INT_ARRAY
, for example).
I'm not sure if that's relevant to this patch though.
UPGRADE.md
Outdated
@@ -1,3 +1,9 @@ | |||
# Upgrade to NEXT |
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 we open develop
?
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.
Let's open develop
, get everything merged there and then back-port the relevant pieces to master
.
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.
Develop already exists here, it just needs rebase.
@@ -147,30 +146,38 @@ public function getIterator() | |||
/** | |||
* {@inheritdoc} | |||
*/ | |||
public function fetch($fetchMode = null, $cursorOrientation = \PDO::FETCH_ORI_NEXT, $cursorOffset = 0) | |||
public function fetch($fetchMode = null, $_ = null, $__ = null) |
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 we deprecate those parameters?
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.
We should. This particular commit should only go to develop
. Initially, I wanted to get rid of them entirely but here's the trick:
DBAL\PDOStatement
extendsPDOStatement
and implementsResultStatement
, both of which declarefetch()
.- It looks impossible to use a custom PDO statement class which doesn't extend
PDOStatement
sincePDO
instantiates it without calling constructor (this is my current understanding, I may be wrong). - Therefore, the declaration of
ResultStatement::fetch()
and all its implementors should be compatible withPDOStatement::fetch()
.
I'd love to be able to rework DBAL\PDOStatement extends PDOStatement
into a composition and get rid of those parameters entirely but it's technically challenging. Any ideas?
lib/Doctrine/DBAL/Connection.php
Outdated
@@ -75,14 +75,14 @@ class Connection implements DriverConnection | |||
* | |||
* @var integer | |||
*/ | |||
const PARAM_INT_ARRAY = 101; | |||
const PARAM_INT_ARRAY = Statement::PARAM_INT + self::ARRAY_PARAM_OFFSET; |
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.
Is +
intentional? Shouldn't this be |
?
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.
Ah, it is an offset... didn't see that.
lib/Doctrine/DBAL/Connection.php
Outdated
|
||
/** | ||
* Represents an array of strings to be expanded by Doctrine SQL parsing. | ||
* | ||
* @var integer | ||
*/ | ||
const PARAM_STR_ARRAY = 102; | ||
const PARAM_STR_ARRAY = Statement::PARAM_STR + self::ARRAY_PARAM_OFFSET; |
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.
Is +
intentional? Shouldn't this be |
?
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.
Ah, it is an offset... didn't see that.
@@ -19,6 +19,8 @@ | |||
|
|||
namespace Doctrine\DBAL\Driver; | |||
|
|||
use PDO; |
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.
Probably to be removed
@@ -20,6 +20,7 @@ | |||
namespace Doctrine\DBAL\Portability; | |||
|
|||
use Doctrine\DBAL\Cache\QueryCacheProfile; | |||
use PDO; |
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 be removed, I'd say. Use the FQCN in the docblock
@@ -27,6 +29,29 @@ | |||
*/ | |||
class PDOStatement extends \PDOStatement implements Statement |
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 we keep the dependency?
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.
Why? This class will be only loaded if a PDO driver is used in runtime. Currently, all tests pass w/o the PDO extension loaded.
This pull request is meant to be split in two parts:
Or the other way around: everything goes to |
Anyone, have you seen these errors before? Looks irrelevant. |
Travis is messed up today, other build failed due to MySQL not starting... |
@Ocramius the hard dependency hardens the adoption of the DBAL by existing projects. Particularly, SugarCRM is migrating its DB layer to DBAL. It supports several DB platforms but doesn't use or support PDO. Currently, it depends on The absence of a dependency on PDO makes the upgrade from a non-DBAL-based version to the DBAL-based seamless. Otherwise, the customers will be required to have PDO installed for no reason. |
Could you elaborate? I was thinking about replacing |
@morozov ACK on adoption. As for the |
b048689
to
965353c
Compare
b92f436
to
cc7a6ce
Compare
@Ocramius please take a look. Instead of removing additional arguments from the |
@morozov for |
We could. I just don’t have an idea of a better set of signatures. We still need to be able to take variable set of arguments depending on the mode. Do you have any concrete idea? |
Nope, no better ideas so far :-\ |
.travis.yml
Outdated
@@ -306,6 +306,11 @@ jobs: | |||
if: type = pull_request | |||
php: 7.2 | |||
script: | |||
- | |
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 be gone after a rebase, no?
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’ll remove it manually if it doesn’t. I tested the fix here. Gonna rebase develop and this branch tomorrow.
I'm really happy we decided to stick with the FetchMode and ParameterType classes with unprefixed/unsuffixed constant names, it really makes more sense this way. 🎉 |
…ement::bindParam()
…ion to avoid having to replicate the \PDOStatement interface in ResultStatement
The first part of the pull request (prior to the commits labeled
[BC]
) contains the non-breaking changes which should be back-ported tomaster
. The remaining part contains the removal of the dependency and breaking API changes.Fixes: #2953.