-
Notifications
You must be signed in to change notification settings - Fork 55
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
Conversation
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 I think what we need to do is rework the internal cache mechanism, to store items as an associative array along with their |
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! |
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. |
Cool, so I've started adding tests. I've added tests for the Things not tests on
|
$this->cache[ $key ] = $data; | ||
$this->cache[ $key ] = [ | ||
'value' => $data, | ||
'found' => false, // Set to false as not technically found in memcache at this point. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in latest commit.
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:
|
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! |
Hey @jenkoian - sorry for the delay - just wanted to let you know this is actively being worked on. |
@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 👍 / 👎 ). |
Yep! Will do that now |
Here you go: #44 once merged I can rebase this if you need 👍 |
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.
@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! |
There was a problem hiding this 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!
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 cachefalse
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):
git fetch origin +refs/pull/43/merge && git checkout FETCH_HEAD
composer install
git revert 5426f2c
vendor/bin/phpunit
(or justphpunit
if you have it globally)git reset
vendor/bin/phpunit
(or justphpunit
if you have it globally)