Skip to content

Fix #69592: pdo_dblib option to skip empty rowsets #2846

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

Closed
wants to merge 4 commits into from

Conversation

fandrieu
Copy link
Contributor

This adds a new attribute PDO::DBLIB_ATTR_SKIP_EMPTY_ROWSETS to enable automatic skipping of empty rowsets.

This happens with some sql statements (like print or set): a rowset with 0 columns is returned by the driver.
With this option enabled 0 columns rowsets are automatically skipped, mirroring the behavior of the former mssql driver.

Credits go to MiRacLe-RPZ for developping and promoting this patch.
The PR is an attempt to resurect #1758 by the original author

This adds a new attribute PDO::DBLIB_ATTR_SKIP_EMPTY_ROWSETS
to enable automatic skipping of empty rowsets.

This happens with some sql statements (like print or set):
a rowset with 0 columns is returned by the driver.

With this option enabled 0 columns rowsets are automatically skipped,
mirroring the behavior of the former mssql driver.

Credits go to MiRacLe-RPZ for developping and promoting this patch.
@KalleZ
Copy link
Member

KalleZ commented Oct 12, 2017

cc'ing maintainer @adambaratz

Bugfix: revert erroneous delete...
Add as a __construct driver option
} while (H->skip_empty_rowsets && num_fields <= 0 && ret == SUCCEED);


if (H->skip_empty_rowsets && num_fields <= 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be better to move this check after the one for FAIL == ret. There might be a situation where you could wind up suppressing a desired error message. The return values would otherwise be the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess it could happen (in case of en empty rowset with an error), I just moved the check after the two others.
From my understanding this new check is a failsafe, in case of an empty rowset and a "ret" value different from FAIL and NO_MORE_RESULTS, so it might as well be the last one...

@adambaratz
Copy link
Contributor

Aside from the one comment I left, looks fine. Could you confirm that the proposed change won't have any undesirable side effects?

Fix error handling in next_rowset
@fandrieu
Copy link
Contributor Author

As far as I know, with the option off the behavior is exactly the same as before, so aside from a bug there should not be any undesirable effect.

Also in my opinion skipping those empty rowsets is the safest practice: that was the former mssql driver behavior and it makes our code resilient to a change in SQL (if a junk-rowset-producing statement is added to the query the consuming code doesn't need to be updated).

Moreover from what I gather, since a recent patch (this one, distributed since 1.00.23) FreeTDS can now produce empty rowsets in between regular ones (whereas before it happened only before the first real one) and so code relying on the default behavior might have to be updated.

My 2 cents is that most code actualy dealing with multiple rowsets either implements this fix in php (as you suggested in the bug report) or work around it in SQL.

@adambaratz
Copy link
Contributor

adambaratz commented Oct 17, 2017

I've merged this in (014fd21). The PR tool isn't working for me at the moment. When it comes back up, I'll close the PR. Thanks, @fandrieu, for helping get this change ready for release.

@php-pulls
Copy link

Comment on behalf of adambaratz at php.net:

merged into master

@php-pulls php-pulls closed this Oct 17, 2017
@fandrieu fandrieu deleted the bug-69592 branch October 18, 2017 15:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants