Collection cache key?

[meiyasan]

Hello,

There are many subtleties in doctrine that I don't understand.
But why the collection cache is based on an key that involve rootEntityName ?

For instance how does it works in the following case:

#[Entity] // <--- Some entity declaration using discrimination map
class CommonClass {}

class ExtendedClassA extends CommonClass
{
      #[ManyToOne...]
      protected $attribute;
}

class ExtendedClassB extends CommonClass
{
      #[ManyToOne...]
      protected $attribute;
}

The code below should be computing a key that is something like : "commonClass_XX_attribute" in both cases and so this might conflict right ? (I am looking for a second level cache issue in one application and that's how I end up here)

orm/lib/Doctrine/ORM/Cache/Persister/Entity/AbstractEntityPersister.php

Line 610 in ed56f42

return new CollectionCacheKey($metadata->rootEntityName, $association['fieldName'], $ownerId);

This is actually same for timestampKey, right ?

orm/lib/Doctrine/ORM/Cache/Persister/Entity/AbstractEntityPersister.php

Line 97 in ed56f42

$this->timestampKey = new TimestampCacheKey($this->class->rootEntityName);

Thank you for your help :o)

[mpdude]

Personally, I have never used the L2 cache, so take my answer with a grain of salt.

These two PRs look related to your question:

• Collection cache key is built differently on read than on write #1552
• Entity cache key is built differently on read than on write #1559

In fact, the first one changed the cache key computation from the sourceEntity name (which would be something I'd expect) to the root entity classname, but does not further explain or mention this. If there is weak test coverage in that area, a slight change like this one may slip through and is not immediately obvious.

The second PR applied a similar-looking refactoring in another area, also switching to the root entity name without further exaplanation. It contains a test case that might help you to write a "reproducer" test yourself.

In my experience, the possibility of having to deal with entity inheritance and/or mapped superclasses is often overlooked, so you might very well have found a valid bug.

My recommendation would be to report that bug as a PR against the 2.14.x branch, with the PR adding a new, failing test. Have a look at the tests/Doctrine/Tests/ORM/Functional/Ticket directory; that's a good place where your new test could live.

[mpdude]

Oh, extra question: If you have one more entity class that, say, extends ExtendedClassB: Would you expect ExtendedClassB and that new class to share the collection cache, or use separate keys? Can you give reasons for your preference?

[meiyasan]

If ExtendedClassBC extends from ExtendedClassB, I expect them to share yes for a common attribute declared in B, but not based on rootEntityName, rather ExtendedClassB::class