-
Notifications
You must be signed in to change notification settings - Fork 62
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
Implement "in memory" backend #39
Implement "in memory" backend #39
Conversation
References python-cachier#4 and references python-cachier#6
Now, the default is calculated dynamically to maintain previous behavior to default to pickle unless the ``mongetter`` argument is given. This makes it have the same behavior as before, so users aren't forced to change old code to use the ``backend`` argument
Closes python-cachier#6 Still needs unit tests
@shaypal5 these are copied from the pickle tests, the only one failing is test_memory_being_calculated. I could use your help with the implementation of the relevant function becuase I don't think I understand the threading part
|
||
def wait_on_entry_calc(self, key): | ||
entry = self.cache[key] | ||
# I don't think waiting is necessary for this one |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it turns out this assumption isn't at all correct 😆
Yes, you need locking for thread safety. :) I'm pulling this into a branch here and I'll add the locking functionality myself + README additions. |
backend : str, optional | ||
The name of the backend to use. If None, defaults to 'mongo' when | ||
the ``mongetter`` argument is passed, otherwise defaults to 'pickle'. | ||
Valid options currently include 'pickle' and 'mongo'. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add 'memory' as a valid option.
@shaypal5 the change of merge target was a bit unexpected, I think it's much better to just push to my branch for consistency. Anyway I hope that my commits don't get squashed and lost in the history once you finish it :) |
I just didn't want to have to wait for you to approve PRs from me to your branch, to then just have these as part of this PR. That sounds like a vicious cycle of waiting. I just wanted to get this done. :) |
And I AM going to squash all your commits into a single one, just for a more readable history. I've started to use dynamic rebasing a lot recently, and can finally appreciate how important it can be to maintain clean commit history. :) |
Nice! I think GitHub allows the repo owner to make commits to branches that are in PRs back to the upstream. I've done this before too |
Released in Congrats and great work, @cthoyt ! First major outside contribution to this project! |
Closes #6
This PR implements an "in memory" backend. It mostly excludes all of the locking and waiting functionalities that were in the pickle backend, since the in-memory should have negligible write and read times (in comparison to pickle). I may have misunderstood the purpose of that functionality, so if it's needed, I think it will be easy to put back in.
This PR also includes the changes from #38 because those were necessary to enable switching between multiple backends.
Caveat the tests aren't written in a very reusable way, so I'm not sure the best way to test this without duplicating a lot of code. I'd appreciate some advice/help on what to do here