-
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
Add "In Memory" cache backend. #6
Comments
@techdragon Couldn't you just use Python's built-in |
@techdragon Anyway, is should be the easiest core yet to implement, so I can try and find time for this soon, if you think it will be usefull for you. |
@shaypal5 Sorry for the extremely late reply. Yes I think it would still be useful. There are lots of circumstances where you want to avoid unnecessary disk IO, and also, an in memory one is probably going to be easier to make thread safe. |
Noted. Do you happen to have the time to implement such a component? :) |
Again, due to the package design, this should be pretty simple; you only need to implement an in-memory core, using the structure of the pickle or MongoDB cores as a template, and simply having some in-memory data structure (probably a dictionary). |
@shaypal5 I also have the same interest - would you be willing to accept a PR for this? |
References python-cachier#4 and references python-cachier#6
Willing? I would be delighted! I saw your PR regarding the I think this should be an API breaking change that will warrant version 2.0. Let's come up with a generalized scheme on how cores should get their kwargs - it should be streamlined, and not have the decorator itself changing its constructor signature on every change in a core keyword. Adding This will also bring us one step closer to multi core functionality, have a series of cores ordered linearly, having cache calls cascading fro memory to pickle to mongo, for example. |
Closes python-cachier#6 Still needs unit tests
Add stubs for redis and memory References #4 and references #6 Make default compatible with previous interface 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 Update docs Add tests
Closes #6 Still needs unit tests Update memory_core.py Add tests for memory core @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
Add stubs for redis and memory References #4 and references #6 Make default compatible with previous interface 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 Update docs Add tests
Released in Congrats and great work, @cthoyt ! First major outside contribution to this project! |
This looks like a solid cache tool, but lack of an in memory backend to both avoid filesystem interaction and not require an external dependency like running mongodb, is a pretty big hinderance for me.
The text was updated successfully, but these errors were encountered: