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

[6.x] Introduce a locking mechanism for the array cache driver #30253

Merged
merged 1 commit into from Oct 14, 2019

Conversation

@timacdonald
Copy link
Contributor

timacdonald commented Oct 12, 2019

This PR introduces a locking mechanism to the array cache driver, for testing.

It is currently not possible to substitute the array cache driver in tests for any driver that supports locking if your test suite / app relies on the locking functionality.

This PR changes that and is something I've wanted for on projects I work on.

This allows me to run the test suite without having to have a lock supporting cache driver running / setup on my machine - which is nice coming into a project and working on parts of a project that don't interact with the cache locking mechanism because it means I can setup and digging into code faster - and it also means a test environment can be setup without requiring a "real" driver like Redis / memcached to be setup and configured.

It's also nice that once you do go down the path of introducing cache locking into your project, you don't have to also change you testing driver. It just continues to work as expected. Related: #29161

I'm happy to package this up if it isn't something you want to add / maintain in the framework.

I'd love if someone could triple check the expiration tests to make sure my logic is sold there, and I don't need to shift the boundary forward a microsecond

Not that is really matters, because the in memory cache drivers are so fast...but this is faster than, say, memcached. But, like, both are so quick...it isn't going to have a speed impact because the difference is negligible. I just thought I'd mention it.

@timacdonald timacdonald force-pushed the timacdonald:lock branch from 3cc1ffd to bb810d0 Oct 12, 2019
@taylorotwell taylorotwell merged commit cde2375 into laravel:6.x Oct 14, 2019
2 checks passed
2 checks passed
continuous-integration/styleci/pr The analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@taylorotwell

This comment has been minimized.

Copy link
Member

taylorotwell commented Oct 14, 2019

Nice work 👍

@driesvints

This comment has been minimized.

Copy link
Member

driesvints commented Oct 14, 2019

@timacdonald nice work dude!

@timacdonald

This comment has been minimized.

Copy link
Contributor Author

timacdonald commented Oct 14, 2019

Thanks! Hopefully it'll be useful to others as well :)

@barryvdh

This comment has been minimized.

Copy link
Contributor

barryvdh commented Oct 17, 2019

Nice! It always bothered me that I couldn't test it locally also.

Could we add locking to other drivers as well, even though they might not be 100% atomic? To make it possible to use the same codepath locally, when not using redis for example.

@Spartaques

This comment has been minimized.

Copy link

Spartaques commented Oct 18, 2019

I spent a lot of time for understanding what's going on and when i understood that it's all because array driver not support locking i was very hungry. But for now it's not a problem. Good work)

@Spartaques

This comment has been minimized.

Copy link

Spartaques commented Oct 18, 2019

@timacdonald

This comment has been minimized.

Copy link
Contributor Author

timacdonald commented Oct 21, 2019

@Spartaques great to hear it'll be handy for you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.