-
Notifications
You must be signed in to change notification settings - Fork 21
Relationships don't construct cache keys correctly #109
Comments
Ping @lox -- I'm not really sure how to approach this one. |
Ok cool, I'll see what I can do. Any chance you could commit a failing testcase to a branch? |
The test that now fails (`IncludesTest::testIncludesHitsCache()`) was only passing because there was a 1-to-1 mapping between the IDs of related entities. I.e. Hero with ID=1 corresponds to SecretIdentity with ID=1, etc. This forces SecretIdentity IDs to start at 100, which exposes the bug discussed in #109.
This is a slightly simpler failing test: 1d0632d |
Any progression on this? Maybe we can start preparing a 1.4 release which introduces |
@lox is there any progress on this? Is there anything I can do to help speed things up? |
We fixed this here: The fix was narrow for our use case, so ymmv. |
Cool! Would you mind testing this against the test in 1d0632d? |
If this fixes the issues, I'll merge and release promptly. |
Fixed in #126 |
The cache key is incorrectly constructed in
BelongsTo::get()
andHasOne::get()
.In
BelongsTo::get()
, the cache key is constructed something like this:Using an example from the test suite:
$object
is an instance ofHero
$this->class
is the class of the related object, i.e.SecretIdentity
$this->foreign
is the name ofSecretIdentity
's primary key column, e.g.id
.For a
Hero
withid = 1
andidentityid = 2
, the above code will generate a cache key ofSecretIdentity[id=1]
instead ofSecretIdentity[id=2]
.I believe the test suite is only passing because the sequences table is wiped each time, and so each
Hero->id
always matchesSecretIdentity->id
.The text was updated successfully, but these errors were encountered: