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

Potential fix for $found issue #40 #43

Merged
merged 5 commits into from
Jan 31, 2020

Conversation

jenkoian
Copy link
Contributor

@jenkoian jenkoian commented Dec 4, 2019

There are 2 commits here.

1a5f667
The first one is a stab at fixing #39 - I couldn't get memcache set up on travis though and only managed to do it locally by using a VM. Longer term it probably needs some more thought, maybe docker or something. However, if you have an environment with memcache setup, the tests should run ok. The test added should prove the bug.

5426f2c
This is the suggested fix. It seems very simplistic which makes me a little suspicious, however https://www.php.net/manual/en/memcache.get.php#refsect1-memcache.get-returnvalues confirms that false will be returned if retrieval fails so I think it should be ok. I was worried that we would want to legitimately want to cache false values, but I'm not sure we can?

Assuming you have a local environment (or VM or something) with memcache all set up, here's how I suggest reviewing this PR (note I haven't tested all of these commands):

  • Check out the PR: git fetch origin +refs/pull/43/merge && git checkout FETCH_HEAD
  • Run composer (or use global phpunit if you'd prefer): composer install
  • Revert the second commit: git revert 5426f2c
  • Run tests: vendor/bin/phpunit (or just phpunit if you have it globally)
  • Notice failure verifying the bug
  • Reset the branch: git reset
  • Run tests again: : vendor/bin/phpunit (or just phpunit if you have it globally)
  • Notice tests now pass

@nickdaugherty
Copy link
Contributor

nickdaugherty commented Dec 5, 2019

Thanks for adding all the tests @jenkoian, that's great!

For the fix - I believe it's not actually fixing the underlying problem, b/c it's returning false for $found when the value was false - the $found param exists to distinguish the two, but currently the code ties them back together without actually tracking if it was found in memcached or not.

I think what we need to do is rework the internal cache mechanism, to store items as an associative array along with their $found status. Currently it's one dimensional so we can only store the value for each key, not "extras" like $found.

@jenkoian
Copy link
Contributor Author

jenkoian commented Dec 5, 2019

Thanks for the feedback @nickdaugherty I've added a new commit which I think is the kind of thing you mean?? I need to add a bunch more tests to verify this first, but wanted to get your initial feedback on direction. Thanks!

@nickdaugherty
Copy link
Contributor

Yep you got it @jenkoian - that's exactly what I was meaning. Since it's a pretty large change to the internals, we'll want to be sure the tests cover as many cases as possible.

@jenkoian
Copy link
Contributor Author

Cool, so I've started adding tests. I've added tests for the add method so far. I'll continue to add tests as and when I can. There's a few things which are going to be tricky to test without some bigger refactorings, I'll leave them for now and maybe we can reflect on them at the end.

Things not tests on add()

  • The unsetting of local cache on memcache failure (I think this would involve refactoring to inject memcache so we can inject a mock for testing)

$this->cache[ $key ] = $data;
$this->cache[ $key ] = [
'value' => $data,
'found' => false, // Set to false as not technically found in memcache at this point.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nickdaugherty are you able to confirm if this should be true or false at this point?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this, I'm wondering if we set to false here (in case someone is using no_mc_groups but then if the set is successful further down, we update the found in the local cache to be true? WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but then if the set is successful further down, we update the found in the local cache to be true

This sounds like the way to go to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in latest commit.

@jenkoian
Copy link
Contributor Author

jenkoian commented Dec 19, 2019

Hi @nickdaugherty,

Been working on the tests any chance I've had and now think the tests should be pretty comprehensive. There are cases where I don't think a test could be written without larger scale refactoring, so I've marked those tests as skipped.

Are you able to have a look, maybe run the tests locally and let me know if you think this is good to go?

Things still left to do:

  • Squash commits
  • Get travis set up

@jenkoian
Copy link
Contributor Author

Update: Have added a travis config file (you can see a passing build here jenkoian#1 don't have the permissions to set it up for this repo) and squashed the commits.

Only thing outstanding I think is a response on this: #43 (comment)

Thanks!

@nickdaugherty
Copy link
Contributor

Hey @jenkoian - sorry for the delay - just wanted to let you know this is actively being worked on.

@nickdaugherty
Copy link
Contributor

nickdaugherty commented Jan 31, 2020

@jenkoian this is looking really great, thank you for all your hard work on it. The test coverage in particular is 💯

I'm having trouble getting the tests running locally - to get Travis going on the repo, can you open a new PR that includes just the test scaffolding + .travis.yml file? That way we can have Travis pre-configured and then can let it run the tests for this PR (rather than waiting until merge to have Travis give a 👍 / 👎 ).

@jenkoian
Copy link
Contributor Author

Yep! Will do that now

@jenkoian jenkoian mentioned this pull request Jan 31, 2020
@jenkoian
Copy link
Contributor Author

Here you go: #44 once merged I can rebase this if you need 👍

Ian Jenkins added 3 commits January 31, 2020 22:07
This will allow us to update the $found parameter accurately when used.

Also added a bunch of tests to make sure this doesn't cause regression
and added a travis config file so tests can be run on travis.
@jenkoian
Copy link
Contributor Author

jenkoian commented Jan 31, 2020

@nickdaugherty ok, rebased this against master and sorted a few rough edges. Let me know if you want me to squash commits or anything. Thanks!

Copy link
Contributor

@nickdaugherty nickdaugherty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks so much for working on this!

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