Skip to content
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

Closed
techdragon opened this issue May 16, 2017 · 8 comments · Fixed by #39
Closed

Add "In Memory" cache backend. #6

techdragon opened this issue May 16, 2017 · 8 comments · Fixed by #39

Comments

@techdragon
Copy link

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.

@shaypal5
Copy link
Collaborator

shaypal5 commented May 16, 2017

@techdragon cachier is meant to provide a persistent cache - as in persistent over different sessions, kernels and even machines - so I naturally thought in-memory storage is not relevant for this.

Couldn't you just use Python's built-in functools.lru_cache for fast in-memory caching?
Or are you thinking about Python processes that live for a long time - weeks or months - like servers, for which you want to cache the return values of different functions for different periods of time, so cachier's stale_after functionality is what you're missing in Python's lru_cache?

@shaypal5
Copy link
Collaborator

@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.

@techdragon
Copy link
Author

@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.

@shaypal5
Copy link
Collaborator

Noted. Do you happen to have the time to implement such a component? :)

@shaypal5
Copy link
Collaborator

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).

@cthoyt
Copy link
Contributor

cthoyt commented Oct 21, 2020

@shaypal5 I also have the same interest - would you be willing to accept a PR for this?

cthoyt added a commit to cthoyt/cachier that referenced this issue Oct 21, 2020
@shaypal5
Copy link
Collaborator

Willing? I would be delighted!

I saw your PR regarding the backend keyword, so I'll tell you what:

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 **kwargs and having cores looking there is definitely an option.

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.

cthoyt added a commit to cthoyt/cachier that referenced this issue Nov 17, 2020
Closes python-cachier#6

Still needs unit tests
shaypal5 pushed a commit that referenced this issue Nov 17, 2020
References #4 and references #6
shaypal5 pushed a commit that referenced this issue Nov 17, 2020
Closes #6

Still needs unit tests
shaypal5 pushed a commit that referenced this issue Nov 17, 2020
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
shaypal5 pushed a commit that referenced this issue Nov 17, 2020
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
shaypal5 pushed a commit that referenced this issue Nov 25, 2020
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
@shaypal5
Copy link
Collaborator

Released in v1.5.0 !!! 🥇 🥳

Congrats and great work, @cthoyt ! First major outside contribution to this project!
I'm so proud. May it be the first of many (by you and/or users of the package)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants