Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-118221: Always use the default row factory in sqlite3.iterdump()#118223

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

@erlend-aasland
Copy link
Contributor

@erlend-aaslanderlend-aasland commentedApr 24, 2024
edited by bedevere-appbot
Loading

The iterdump() implementation depends on the row factory returning
resulting rows as tuples; it will fail with custom row factories like
for example a dict factory.

Fixed by overriding the row factory of the cursor used by iterdump().
FTR, this does not affect the row factory of the parent connection.

…mp()The iterdump() implementation depends on the row factory returningresulting rows as tuples; it will fail with custom row factories likefor example a dict factory.Fixed by overriding the row factory of the cursor used by iterdump().FTR, this does not affect the row factory of the parent connection.
@erlend-aasland
Copy link
ContributorAuthor

@kesry, can you see if this patch works for you?

@erlend-aasland
Copy link
ContributorAuthor

cc.@felixxm who has poked around in theiterdump() implementation lately.

Copy link
Contributor

@felixxmfelixxm left a comment

Choose a reason for hiding this comment

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

@erlend-aasland Thanks 👍

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
@erlend-aasland
Copy link
ContributorAuthor

Thanks for the review, Mariusz! I'll land this later this week, in case anyone else wants to take a look.

@erlend-aaslanderlend-aasland self-assigned thisApr 24, 2024
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
@kesry
Copy link

cc.@felixxm who has poked around in theiterdump() implementation lately.

That's good, thanks!

@erlend-aasland
Copy link
ContributorAuthor

Thanks for the review, Serhiy!

@erlend-aaslanderlend-aasland merged commite38b43c intopython:mainApr 25, 2024
@erlend-aaslanderlend-aasland deleted the sqlite/iterdump-custom-row-factory branchApril 25, 2024 08:11
@miss-islington-app

This comment was marked as outdated.

@miss-islington-app

This comment was marked as outdated.

@bedevere-app
Copy link

GH-118270 is a backport of this pull request to the3.12 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.12only security fixes labelApr 25, 2024
erlend-aasland added a commit that referenced this pull requestApr 25, 2024
…ump() (#118223) (#118270)sqlite3.iterdump() depends on the row factory returning resulting rowsas tuples; it will fail with custom row factories like for example adict factory.With this commit, we explicitly reset the row factory of the cursor usedby iterdump(), so we always get predictable results. This does notaffect the row factory of the parent connection.Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
@bedevere-bot

This comment was marked as off-topic.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@serhiy-storchakaserhiy-storchakaserhiy-storchaka approved these changes

@berkerpeksagberkerpeksagAwaiting requested review from berkerpeksagberkerpeksag is a code owner

+1 more reviewer

@felixxmfelixxmfelixxm left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

@erlend-aaslanderlend-aasland

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@erlend-aasland@kesry@bedevere-bot@felixxm@serhiy-storchaka

[8]ページ先頭

©2009-2025 Movatter.jp