Odd and potentially unintuitive behavior when using Cache::tags()

[BrekiTomasson]

Say I have something like the following in my User model:

public function getCachedName() : string
{
    return Cache::tags(['users', 'user.' . $this->id])->remember('name', 3600, fn () => $this->name);
}

If I then do something like:

> $user = User::find(36);
> $user->getCachedName()
=> "Kevin"

Under the hood, this will store the $name property of User 36 using the cache key name, tagging it with both users and user.36. While this is cached, I will be able to get this value by doing something like Cache::tags(['users', 'user.36'])->get('name'), just as one would expect.

If I want to forget everything having to do with User 36, I can Cache::tags('user.36')->flush(), which would mean Cache::tags(['users', 'user.36'])->get('name') would return null but Cache::tags(['users', 'user.23'])->get('name') would return the name of User 23 (assuming i've stored the name of User 23 previously, of course). I can also Cache::tags('users')->flush() and neither the user.36 or the user.23 versions of that query would return a value other than null.

So far, so good. Everything is working as expected and we can define our keys with much simpler names by moving some of the responsibilities into the tags rather than the more verbose Cache::tags('users')->put('36:name', 'Kevin') or Cache::put('user:36:name', 'Kevin'), for example.

However, there are three use cases where the way cache tags works becomes somewhat unintuitive, one of which feels entirely broken. They are:

1. Accessing a key using a subset of the tags:

When you define a cache key with two or more tags, you cannot access the key using a subset of those tags, even if the result would be unique.

> Cache::tags(['users', 'user.36'])->put('name', 'Kevin');
> Cache::tags('user.36')->get('name');
=> null

I can kind of understand this one, since there is no guarantee that the key you used will be unique for any one of the tags you included. Changing this to return 'Kevin' would require Cache::tags('users')->get('name') to throw an exception of some kind as there are multiple keys called name that use the same underlying tag and your request needs to be made more specific. This would most likely be a breaking change and, as such, I'd say this is working as intended.

Still; it's somewhat unexpected behavior and might need better documentation.

2. Changing the order of your cache tags:

For some reason, when you get() a value using a Cache that you've tagged with an array, you need to name the cache tags in the exact same order that they were defined when you put() the name there.

> Cache::tags(['users', 'user.36'])->put('name', 'Kevin');
> Cache::tags(['user.36', 'users'])->get('name');
=> null

This is entirely unexpected and - in my opinion - broken. Laravel should, under the hood, sort the array passed into tags() so that it doesn't matter in which order the cache tags are provided.

3. Changing all values of a tag Subset

You cannot 'bulk replace' tags by providing a new value for one or more of its tags.

> Cache::tags(['users', 'user.36'])->put('name', 'Kevin');
> Cache::tags('users')->put('name', 'Jeremy');
> Cache::tags('user.36')->put('name', 'Timmy');
> Cache::tags(['users', 'user.36'])->get('name');
=> 'Kevin'

Again, this most likely has to do with how Laravel converts the contents of tags() to something else under the hood, but again, this is somewhat unexpected behavior, especially when you think of how you can flush() any one of the tags to remove the value:

> Cache::tags(['users', 'user.36'])->put('name', 'Kevin');
> Cache::tags('users')->flush();
> Cache::tags(['users', 'user.36')->get('name');
=> null