Add $entityRepository->getNext() and $entityRepository->getPrevious() #7166

New Issue

admin · 2026-01-22T15:45:57+01:00

admin commented

2026-01-22 15:45:57 +01:00

Originally created by @nbennett25 on GitHub (Jun 9, 2023).

Feature Request

Q	A
New Feature	yes
RFC	yes/no
BC Break	yes/no

Summary

It'd be super nice to have methods to get the prev/next entity record built directly into the framework. The only solutions I've seen use raw sql to query for the next/prev available record table id. Given that most tables should have a unique identifier, we should be able to query the class metadata to determine which record to return.

$entityRepository = $this->getDoctrine()->getManager()->getRepository(Entity::class);

$entity = $entityRepository->find(3);

$previousEntity = $entityRepository->find($entity->getId())->getPrevious();
$nextEntity = $entityRepository->find($entity->getId())->getNext();

Originally created by @nbennett25 on GitHub (Jun 9, 2023). ### Feature Request  | Q | A |------------ | ------ | New Feature | yes | RFC | yes/no | BC Break | yes/no #### Summary It'd be super nice to have methods to get the prev/next entity record built directly into the framework. The only solutions I've seen use raw sql to query for the next/prev available record table id. Given that most tables should have a unique identifier, we should be able to query the class metadata to determine which record to return. ``` $entityRepository = $this->getDoctrine()->getManager()->getRepository(Entity::class); $entity = $entityRepository->find(3); $previousEntity = $entityRepository->find($entity->getId())->getPrevious(); $nextEntity = $entityRepository->find($entity->getId())->getNext(); ```

admin closed this issue

2026-01-22 15:45:57 +01:00

admin commented

2026-01-22 15:45:58 +01:00

@derrabus commented on GitHub (Jun 10, 2023):

Your proposal implies that repositories hold a state of what the "current" record is and have an opinion on some kind of order of entities. I don't think that adding either of those aspects to the repository is a good idea, to be honest.

@derrabus commented on GitHub (Jun 10, 2023): Your proposal implies that repositories hold a state of what the "current" record is and have an opinion on some kind of order of entities. I don't think that adding either of those aspects to the repository is a good idea, to be honest.

admin commented

2026-01-22 15:45:58 +01:00

@ghost commented on GitHub (Jun 10, 2023):

Actually the issue title say something different than the code sample. In title we can see $repo->getNext() and inside code sample we can see $repo->find()->getNext() what means that this is the entity that returns next one.

@ghost commented on GitHub (Jun 10, 2023): Actually the issue title say something different than the code sample. In title we can see `$repo->getNext()` and inside code sample we can see `$repo->find()->getNext()` what means that this is the entity that returns next one.

admin commented

2026-01-22 15:45:58 +01:00

@greg0ire commented on GitHub (Jun 10, 2023):

Doctrine does not use active record, so we can't add extra methods to entities. Let's close this then.

@greg0ire commented on GitHub (Jun 10, 2023): Doctrine does not use active record, so we can't add extra methods to entities. Let's close this then.

admin commented

2026-01-22 15:45:59 +01:00

@nbennett25 commented on GitHub (Jun 12, 2023):

@derrabus I agree, the repository probably shouldn't be aware of the 'current' record, but I don't see a reason why the repository couldn't return the 'next' record, given and entity as initial position and a unique identifier to determine the prev/next record.

I would much rather defer to the ORM to determine a 'next' entity, but if the only manner to achieve this is raw SQL then raw SQL it is (but it feels like a shortcoming)

@nbennett25 commented on GitHub (Jun 12, 2023): @derrabus I agree, the repository probably shouldn't be aware of the 'current' record, but I don't see a reason why the repository couldn't return the 'next' record, given and entity as initial position and a unique identifier to determine the prev/next record. I would much rather defer to the ORM to determine a 'next' entity, but if the only manner to achieve this is raw SQL then raw SQL it is (but it feels like a shortcoming)

admin commented

2026-01-22 15:45:59 +01:00

@ghost commented on GitHub (Jun 13, 2023):

It's not possible to determine next entity because there are many types of identifiers. Only with sequentially incremented IDs it could be possible but not with uuid, custom id strategies etc.

@ghost commented on GitHub (Jun 13, 2023): It's not possible to determine next entity because there are many types of identifiers. Only with sequentially incremented IDs it could be possible but not with uuid, custom id strategies etc.

admin commented

2026-01-22 15:45:59 +01:00

@derrabus commented on GitHub (Jun 13, 2023):

@derrabus I agree, the repository probably shouldn't be aware of the 'current' record, but I don't see a reason why the repository couldn't return the 'next' record, given and entity as initial position and a unique identifier to determine the prev/next record.

If the repository does not know the current record, it cannot determine the next record. 🤷🏻‍♂️ On top of that, entities are not ordered in any way, so even if the repository somewhat magically knew the current entity, it could not tell which entity to load as the next or previous one.

Only with sequentially incremented IDs it could be possible

And even in that case, the assumption that an autoincrement defines the order of entities is a guess. If we make that assumption, someone will open a PR pretty quickly to make the order configurable.

To put it in a nutshell: The proposed feature would require us to introduce many new concepts to the ORM (pointers to "current entities", an order of entities) for very little gain. On top of that, the feature could easily be built in userland.

@derrabus commented on GitHub (Jun 13, 2023): > @derrabus I agree, the repository probably shouldn't be aware of the 'current' record, but I don't see a reason why the repository couldn't return the 'next' record, given and entity as initial position and a unique identifier to determine the prev/next record. If the repository does not know the current record, it cannot determine the next record. 🤷🏻‍♂️ On top of that, entities are not ordered in any way, so even if the repository somewhat magically knew the current entity, it could not tell which entity to load as the next or previous one. > Only with sequentially incremented IDs it could be possible And even in that case, the assumption that an autoincrement defines the order of entities is a guess. If we make that assumption, someone will open a PR pretty quickly to make the order configurable. --- To put it in a nutshell: The proposed feature would require us to introduce many new concepts to the ORM (pointers to "current entities", an order of entities) for very little gain. On top of that, the feature could easily be built in userland.

admin commented

2026-01-22 15:46:00 +01:00

@nbennett25 commented on GitHub (Jun 20, 2023):

Fwiw, I think an argument can be made that a repository class, given an entity, and a criteria for determining a next/prev record (even a sortBy clause), should be able to return a next/prev entity.

@nbennett25 commented on GitHub (Jun 20, 2023): Fwiw, I think an argument can be made that a repository class, given an entity, and a criteria for determining a next/prev record (even a sortBy clause), should be able to return a next/prev entity.

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#7166