Skip to content
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

Fix pg boolean conversion #625

Merged
merged 42 commits into from
Jun 30, 2014

Conversation

lucasvanlierop
Copy link
Contributor

Merge of complementary PR's #527 and #564 + some fixes. Contributing it as an result of the (extended) phpconference.nl 2014 hackathon.

@lucasvanlierop lucasvanlierop changed the title Fix pg boolean conversion [WIP] Fix pg boolean conversion Jun 26, 2014
@stof
Copy link
Member

stof commented Jun 26, 2014

This branch needs to be rebased as it conflicts with master (and changes shpoould probably be squashed a bit)

@Ocramius
Copy link
Member

@lucasvanlierop thanks for taking care of this. Maybe I can catch you during the conference and we can discuss the PR together :-)

@lucasvanlierop
Copy link
Contributor Author

@stof, PR is now up to date with master, I will squash the whole thing when it's finished.

@Ocramius, yes good idea, currently I'm at the point where I think boolean conversion deserves it's own class instead of having lots of extra methods in de platform class. But I don't know if you like that idea? Maybe we can use part of the lunch break to discuss it?

*
* @param mixed $item
*
* @return bool
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bool|null

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

*
* @param mixed $item
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as discussed, more precise types here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, I would like to do it but not possible.

@lucasvanlierop
Copy link
Contributor Author

@davividal and @birko I've merged both your PR's (#564 and #527) into one new PR handling both the conversion from Postgresql database boolean values to php and vice versa. Please check if it still is what you meant it to be. I'm just here to help out with longstanding open PR's.

@deeky666, Would you review this as you commented on the original PR's and also suggested part code @davividal has contributed.

@lucasvanlierop lucasvanlierop changed the title [WIP] Fix pg boolean conversion Fix pg boolean conversion Jun 29, 2014
@deeky666
Copy link
Member

At the first glance this PR looks good so far. Something that we didn't talk about here is possible performance implications. I talked about this issue with @beberlei some time ago and he wasn't happy with all those callbacks. But I don't know really know if that has any impact on performance.
Otherwise I would like to hear from the originals authors again if they are fine with it and afterwards merge?

@lucasvanlierop
Copy link
Contributor Author

@deeky666, thanks for taking a look. Well to be honest the conversion feels a bit over engineered to me but I tried to keep the focus on merging complementary solutions (and some cleaning up) and so I kept the logic more or less like it was.

@deeky666
Copy link
Member

The original implementation had a lot of code duplication and was rather hard to read and understand. Thus I proposed a more "simplified" solution with smaller methods removing the code duplication but I see and understand that those callbacks are rather heavy here. TBH I don't mind which way to go :)
Thanks for putting both PRs together btw.

@davividal
Copy link
Contributor

Looks fine for me.

I don't know how to test performance of the callback implementation, sorry.

@birko
Copy link
Contributor

birko commented Jun 30, 2014

Hmm for me probably ok. If I am looking correctly

@Ocramius
Copy link
Member

@lucasvanlierop can you please remove lucasvanlierop/dbal@15d876f ? Please rebase instead.

birko added 10 commits June 30, 2014 15:44
Default Boolean conversion behaviour
added postgresql literals to Boolean conversion
Changed to call platform specific Boolean conversion
added postgresql platform conversion test
fixed bug when $item was set as bool true value
added 'off' literal
added literals off and on to the testcase
Changes after Ocramius comments
fixed parameter order in conditions
@edigu
Copy link

edigu commented Oct 27, 2014

This problem still continues in PHP 5.6. I think it needs more specific test. See #632

@Ocramius
Copy link
Member

Ocramius commented Nov 5, 2014

Probably related to #714

@mbeccati
Copy link
Contributor

mbeccati commented Nov 6, 2014

Possibly caused by https://bugs.php.net/bug.php?id=68351 - which I've just fixed (sorry I haven't read the full thread here ;) )

@deeky666
Copy link
Member

deeky666 commented Nov 7, 2014

@mbeccati this reads promising. Does it also apply to \PDOStatement::bindValue()? Could you maybe add a test for null values? Because this is what's going wrong here. Inserting a null value into a nullable boolean column with emulated prepares enabled and using \PDOStatement::bindValue(1, null, \PDO::PARAM_BOOL) result in PHP converting null to true in PHP 5.6 while it was converted to false in PHP < 5.6.

@mbeccati
Copy link
Contributor

mbeccati commented Nov 7, 2014

@deeky666 yes, that's precisely what the fix is for. The bug existed in previous versions as well, but it was probably less likely to trigger it.

@deeky666
Copy link
Member

deeky666 commented Nov 7, 2014

@mbeccati awesome! Thanks a lot for taking care of that issue. It has been causing us bad headaches for some time now...

private function convertSingleBooleanValue($value, $callback)
{
if (null === $value) {
return $callback(false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should use call_user_func to support all callables on PHP 5.3

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, given it is a private method, it may not be needed though

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe type-hint Closure?

@edigu
Copy link

edigu commented Dec 22, 2014

@mbeccati The PDO::PARAM_BOOL and ATTR_EMULATE_PREPARES misbehaving bug is fixed in 5.6.4 and 5.5.20. See: https://bugs.php.net/bug.php?id=68351

@Ocramius
Copy link
Member

@edigu awesome! :-)

@deeky666 do you think we should make DBAL conflict with >=5.6.0,<=5.6.3?

@mbeccati
Copy link
Contributor

@Ocramius @deeky666 For reference, the PHP bug I fixed was there since https://bugs.php.net/bug.php?id=62593 was fixed - i.e. 5.4.9+ / 5.3.19+. I'm not even sure what was the behaviour before that.

@stof
Copy link
Member

stof commented Dec 26, 2014

@Ocramius I don't think we should:

  • we don't exclude all PHP versions affected by a bug, otherwise people will just be unable to install the package in many cases. Doing it for a single bug would be inconsistent
  • it only affects the PostgreSQL driver, so why forbidding to use 5.6.0 for people using MySQL ?

@Ocramius
Copy link
Member

why forbidding to use 5.6.0 for people using MySQL ?

Because of unforseen consequences there ("wtf" moments for pgsql users, mysql is fine). Anyway, users are still free to upgrade, and I agree with you on the users that are not affected by the bug.

I guess the only required change is a travis upgrade of PHP 5.6 (once available)

@deeky666
Copy link
Member

We could just document this incompatibility somewhere. Otherwise the only solution I see is to make PDO_PGSQL not use emulated prepares for those versions to stay compatible. But that would also require adjusting the PDO implementation DBAL wise....

@PowerKiKi
Copy link
Contributor

Just to confirm that upgrading PHP from 5.6.3 to 5.6.4 indeed solved that bug for me without any other changes.

Also I agree with @deeky666 that it should be documented somewhere as known bugs.

@deeky666
Copy link
Member

I'd say let's wait for travis to go for 5.6.4, see the build result and then add a section in the documentation. Not going too complicated here, we cannot deal with everything....

@Vincent-Simonin
Copy link

Hello,
Since DBAL v2.4.3 we can't handle null value on boolean field : false is returned instead of null.
Is this normal ?

@edigu
Copy link

edigu commented Feb 27, 2015

@Vincent-Simonin what is your php version?

@Vincent-Simonin
Copy link

@edigu v5.5.22

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants