-
Notifications
You must be signed in to change notification settings - Fork 121
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
Bump to v3? #60
Comments
See also: #61 Thanks! |
@elistevens when you do "rsync" backups take careful note of the switches used. The test_rsync test was failing intermittently when using "rsync" without "--checksum". As I understand it, rsync checks file sizes and modification times to heuristically determine which files have been modified (this is the default behavior). For a little database like sqlite which is quickly edited and uses an underlying block storage, it's possible to modify the database but retain the same size and modification time. You can pass "--checksum" to rsync to tell it not to use it's default heuristic and instead compare checksums. This way, you'll still benefit from incremental transfers. But if you were exceedingly paranoid, you might not trust the checksums and choose "--ignore-times" which will transfer all files and behave like a copy. The switches I'm using in testing are:
The purpose of each switch:
|
I'm surprised that the DB could be modified, but the modification time on the file not be updated. For our use case, 99% of the content won't have been changed on a day-to-day basis, so our nightly backups will probably do something like using time+size for rsync, and then making sure the DB has been copied every time. Thanks for letting me know there might be issues there. |
It's not so much that the modification time is not updated but that the resolution of the modification time is less than necessary. I develop on a MacBook Pro with an OS X Extended filesystem. According to Wikipedia and an Ars Technica article (both cited by a Stack Overflow answer), the resolution of the modification time on HFS+ file systems is 1 second. I think it's easy to imagine in testing that multiple modifications to the database could occur within the same second and the database could remain the same size. Considering that you will likely do nightly backups, I doubt it could ever be an issue. I just want you to be aware that rsync uses heuristics (like file size and modification time) and those may be inaccurate. You may also want to use the "-z" option to compress the transfer over rsync. |
Ahh, that makes much more sense. Yeah, that won't be an issue for our use case. Great! |
V3 tagged in git and deployed to PyPI. I'm waiting now to see Travis and AppVeyor come back green. The new diskcache is faster than the old one. Yaay! Always a good sign. I added test_core.py:test_custom_eviction_policy for your custom eviction scenario. I also think the new design (new-style format strings) would allow you to update the expire_time on every get/incr. Something like:
And then just use Also note that with your custom eviction policy, you can exceed the cache's size limit. If the culling query returns no rows then the culling stops regardless of the cache's volume. |
All green in Travis and AppVeyor. I think that meets all the v3 milestones. |
Upcoming features:
.format
strings when cullingThe text was updated successfully, but these errors were encountered: