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

Simple set/get API added #5

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Simple set/get API added #5

wants to merge 1 commit into from

Conversation

qrilka
Copy link

@qrilka qrilka commented Aug 8, 2014

Original get + fun is not quite suitable for our app we use simpe_cache for

@qrilka
Copy link
Author

qrilka commented Aug 13, 2014

Any comments on this?

@marcelog
Copy link
Owner

marcelog commented Oct 2, 2014

I'm not completely sure about the benefit here.. The whole point is to create the value in the cache if it doesn't exist, so the logic of getting/creating the key is encapsulated by simple_cache without any further checks of found/not found in the caller. Can you elaborate a bit more on how are you using it?

Thanks for the pull, by the way, and sorry it took me so long to reploy

@qrilka
Copy link
Author

qrilka commented Oct 2, 2014

Example usecase: I need to check cache and then do the calculation which could lead to some result with no value being cached.
E.g. some token authentication - you check if this token exists in the cache, and if it is not you do some request to remote token checking server which could give ok or {error, Reason} and if you don't receive ok that received value should not be stored in the cache.
I don't see how this could be possible to implement that easily with the current simple_cache API

@marcelog
Copy link
Owner

marcelog commented Oct 2, 2014

Great. What about (in this particular scenario) just let the request crash with something like:

ok = do_request()

That can be done in the function that you pass as argument in the get() function. If the function crashes, nothing will be cached and the caller can trap the error and act accordingly, no double checks are involved and the operation looks "more atomic".

Makes sense?

@qrilka
Copy link
Author

qrilka commented Oct 2, 2014

I came to that variant when I was formulating answer to you.
That looks like an option but it has a bad smell of business logic programmed with exceptioins. I.e. if that error could lead to process crash then it'd be ok but if responding correctly to a bad token is a part of correct implementation then it's not a very good choice.

@marcelog
Copy link
Owner

marcelog commented Oct 2, 2014

if you have to react to the error instead of letting things crash, you can do:

try
  get_and_cache_token(token_cache, 86400000, a_token, fun() ->
    case get_token() of
      ok -> ok;
      {error, Error} -> throw(Error)
    end
  end)
catch
  _:BadError -> deal_with_it(BadError)
end

@qrilka
Copy link
Author

qrilka commented Oct 2, 2014

Yep, that's what I call "business logic programmed with exceptioins" but that's an option of course.

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

Successfully merging this pull request may close these issues.

2 participants