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

Update database.py#104

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

Merged
msiemens merged 3 commits intomsiemens:masterfromKeksKeksKeks:master
Jun 14, 2016
Merged

Update database.py#104

msiemens merged 3 commits intomsiemens:masterfromKeksKeksKeks:master
Jun 14, 2016

Conversation

@KeksKeksKeks
Copy link
Contributor

Don't write db if _default is an empty Table.

If there are no documents in the _default table, TinyDB will write (and thus, re-serialize) the entire database.
This is because bool({}) == False, although the table does exist.

I have a JSON file under version control, which doesn't use the default table. Recently, I noticed that the file changes although I didn't change any document within the database.
Apparently, TinyDB.init reads the default table, which is empty in my case. An empty document evaluates to False in a boolean context, and TinyDB will write a new, empty table, effectively re-serializing the database on read.

Don't write db if _default is an empty Table.If there are no documents in the _default table, TinyDB will write (and thus, re-serialize) the entire database.This is because bool({}) == False, although the table does exist.
This time, don't break the tests.
@KeksKeksKeks
Copy link
ContributorAuthor

Classical case of RTFM :(

I should have read the contribution instructions first. I have added a test to demonstrate the original behaviour, introduced changes to make it go away, and added the neccessary changes to make the coverage check happy.

Kudos for such a thorough code infrastructure! I enjoyed using (and now, contributing to) TinyDB.

@msiemensmsiemens merged commit331bb0d intomsiemens:masterJun 14, 2016
@msiemens
Copy link
Owner

That makes sense, thank you! Just out of curiosity: I find it interesting that the VCS tracks the file modification time. Which one are you using?

@KeksKeksKeks
Copy link
ContributorAuthor

You're welcome!

I use git, which doesn't track file modificationtime. Instead, because python dicts are unordered, two JSON serialisations of the same database will look different. And a different filecontent is, of course, then detected by the VCS.

@msiemens
Copy link
Owner

Ah, I see! Unexpected reordering of Python's dicts have bitten me more than once 😄

@eugene-eeo
Copy link
Contributor

Turns out there is asort_keys option in thejson.dumpsfunction. However Ithink that'd degrade performance slightly, but anyways here it is:http://stackoverflow.com/questions/10844064/items-in-json-object-are-out-of-order-using-json-dumps

msiemens added a commit that referenced this pull requestSep 14, 2016
As mentioned insixty-north/cosmic-ray#171, PR#104 wasn't listedin the changelog for v3.2.1.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@KeksKeksKeks@msiemens@eugene-eeo

[8]ページ先頭

©2009-2025 Movatter.jp