Skip to content

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