findBy from ServiceEntityRepository returning proxies depends if i use orderBy

[oriolvinals]

Hi,

First of all, i don't know if this is a feature or a bug.

So, If someone can help me understand it, I would be grateful.

I have an entity called Invoice for example.

<?php

namespace App\Entity;

use Carbon\CarbonImmutable;
use Doctrine\ORM\Mapping as ORM;


#[ORM\Entity(repositoryClass: InvoiceRepository::class)]
class Invoice extends InvoicingDocument
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column(type: 'integer', options: ['unsigned' => true])]
    private ?int $id = null;

    #[ORM\Column(type: 'carbon_immutable_date', nullable: true)]
    private ?CarbonImmutable $date = null;

    #[ORM\Column(type: 'integer', nullable: true, options: ['unsigned' => true])]
    private ?int $code = null;

    #[ORM\Column(type: 'string', length: FieldLength::Text50)]
    private string $number = '';

    #[ORM\Column(type: 'utc_carbon_immutable')]
    private CarbonImmutable $createdAt;

    // Constructor
    // Getters and setters..
}

Now if i want the invoices using findBy like

$this->invoiceRepository->findBy(['id' => [1,2,3,4,5,6,7,8]], ['code' => 'ASC']);

The majority of values are Invoice::class instance, but one or two can be Proxies\__CG__\App\Entity\Invoice.

If I don't use orderBy all values are Invoice::class instance. If I use orderBy with createdAt works like without orderBy, but using code is returning values with proxy instances.

I know I can use instance of because Proxies\__CG__\App\Entity\Invoice extends from Invoice but I want to know if this is a bug or a feature.

IMHO using orderBy argument would not have to change the instance of the values since are the same data from using or not using orderBy

I'm missing something?

[stof]

Returning proxies or not actually depends on whether the UnitOfWork of the ORM already contains a proxy for a given id.
The rule is that the ORM always manages a single instance for each id. So if a proxy was already created before, it will initialize the existing proxy and keeps using it.
This is one of the core feature of the ORM, not a bug.

[stof]

One thing that could explain the usage of proxies for a different ordering might be that you have a self-referencing association in your entity (not visible in your code snippet). In this case, if your entities are only referencing entities created before them, a sort by creation date will mean that the hydration of each entity never needs to create a proxy because the related entity has already been hydrated for a previous item in the list. With a different ordering (or a sorting by descending creation date) would instead have cases where hydrating an invoice involves a related entity that is not hydrated yet (which then creates a proxy for it), even if another result item corresponds to that related entity later in the list.

[oriolvinals]

Thanks for the answer! That's the reason, i have a ManyToOne relation with another invoice of the list. If the invoice with relation is hydrated first, the related Invoice is a Proxy and when i need the other invoice the UnitOfWork takes the Proxy instead of initialize.

There's a way to ignore this and re-initialize the invoice?

[stof]

It should be initializing the proxy (instead of leaving it in an uninitialized state).

But it cannot replace the proxy with a non-proxy instance. This would require updating all places that currently reference the proxy instance to make them use the new hydrated object instead, and there is no way to do this in PHP (or in any other object-oriented language that I know of for that matter). Otherwise, you end up with 2 object instances for the same id (one in your result list and one inside the property of the ManyToOne of the other invoice).

If code is written in a way respecting OOP principles, the fact that you get an instance of a subclass should not cause any issue. The Liskov Substitution Principle guarantees that the proxy instance can be used in any place expecting an invoice (that's why the proxy class extends the entity class)