Repository methods are not consistent #6109

New Issue

admin · 2026-01-22T15:26:51+01:00

admin commented

2026-01-22 15:26:51 +01:00

Originally created by @arnaud-lb on GitHub (Nov 20, 2018).

Bug Report

Q	A
BC Break	no
Version	2.6

Summary

Repository methods return inconsistent results when persisted entities are not flushed yet.

Current behavior

After calling persist() on a new entity, find() is able to return the entity correctly. However, methods such as findBy() or matching() will ignore new entities.

How to reproduce

Create new entity instance
persist() it
Use findBy()

I've added a test case here: https://github.com/doctrine/doctrine2/compare/2.6...arnaud-lb:inconsistent-repository

Expected behavior

findBy(), matching(), and other methods should behave consistently with find().

This does not seems to be completely unreasonable to implement, since ArrayCollection has an in-memory implementation of matching().

Originally created by @arnaud-lb on GitHub (Nov 20, 2018). ### Bug Report  | Q | A |------------ | ------ | BC Break | no | Version | 2.6 #### Summary Repository methods return inconsistent results when persisted entities are not flushed yet. #### Current behavior After calling `persist()` on a new entity, `find()` is able to return the entity correctly. However, methods such as `findBy()` or `matching()` will ignore new entities. #### How to reproduce - Create new entity instance - persist() it - Use findBy() I've added a test case here: https://github.com/doctrine/doctrine2/compare/2.6...arnaud-lb:inconsistent-repository #### Expected behavior `findBy()`, `matching()`, and other methods should behave consistently with `find()`. This does not seems to be completely unreasonable to implement, since `ArrayCollection` has an in-memory implementation of `matching()`.

admin added the Documentation label 2026-01-22 15:26:51 +01:00

admin commented

2026-01-22 15:26:51 +01:00

@arnaud-lb commented on GitHub (Nov 20, 2018):

I believe that, in an application that uses repositories, everything should be expected to work exactly the same way before and after durable persistence occurred (flush()).

@arnaud-lb commented on GitHub (Nov 20, 2018): I believe that, in an application that uses repositories, everything should be expected to work exactly the same way before and after durable persistence occurred (`flush()`).

admin commented

2026-01-22 15:26:52 +01:00

@beberlei commented on GitHub (Dec 6, 2020):

This is actually not true, EntitManager#find() only returns the entity when it has a "pre persist id generator", which makes sense since we can the put it into the identity map from where it is returned.

The documentation could be better here explaning this in "working with objects".

@beberlei commented on GitHub (Dec 6, 2020): This is actually not true, `EntitManager#find()` only returns the entity when it has a "pre persist id generator", which makes sense since we can the put it into the identity map from where it is returned. The documentation could be better here explaning this in "working with objects".

admin commented

2026-01-22 15:26:52 +01:00

@SenseException commented on GitHub (Dec 6, 2020):

Any suggestions how to formulate this behaviour?

@SenseException commented on GitHub (Dec 6, 2020): Any suggestions how to formulate this behaviour?

admin commented

2026-01-22 15:26:52 +01:00

@beberlei commented on GitHub (Dec 6, 2020):

I think a section about the identity map (it seems not to exist?) would explain when are entities added to or, in which cases it prevents a query, find(), and when it does not prevent tje query, but that it still looks in the map with the id returned from databse row

@beberlei commented on GitHub (Dec 6, 2020): I think a section about the identity map (it seems not to exist?) would explain when are entities added to or, in which cases it prevents a query, find(), and when it does not prevent tje query, but that it still looks in the map with the id returned from databse row

admin referenced this issue

2026-01-22 16:05:37 +01:00

[PR #6109] Support for ClassMetadataInfo::isSingleAssociationJoinColumnNullable() #9854

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6109