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

bounded caches #32

Open
kantp opened this issue Jul 8, 2015 · 2 comments
Open

bounded caches #32

kantp opened this issue Jul 8, 2015 · 2 comments

Comments

@kantp
Copy link

kantp commented Jul 8, 2015

Hi there,

I've been using this great library for some time now, thanks for opening it up to the public!

My use case involves large amounts of data, so I had to change the library slightly to be able to use a bounded cache. I have made it configurable so that each type of request can either use a bounded cache of a given size, or an unbounded cache.

In order to configure it, I have added an additional typeclass that has a DataSource has to be an instance of. It has a single function, cacheSize, that determines the size of the cache for each request (which may be infinite).

If this is useful to other people, I'd be glad to do a pull request. Notice however, that this would be a breaking change, since all DataSources have to add an instance of the new typeclass (which is easy to do).

I have not yet added tests that check that the cache stays within the specified bounds, nor done benchmarks (but it's on my agenda).

Best,
Philipp

@simonmar
Copy link
Contributor

simonmar commented Jul 8, 2015

I can understand the need to limit the cache size in certain use cases. However, as soon as we stop caching everything, we lose the nice replayability property that Haxl has now: the cache is a complete record of the execution, and the request can be replayed without fetching any data.

So I'm open to doing this so long as we can make it non-invasive, and make it clear that it breaks replayability.

@kantp
Copy link
Author

kantp commented Jul 8, 2015

I agree, caching everything should stay the default, since that is the typical use case.

I'll add a default implementation that chooses an unbounded cache and make it explicit in the docs that changing the default sacrifices replayability, before opening a pull request.

@kantp kantp mentioned this issue Jul 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants