Proper way to load relations on a single entity

[sylbru]

This is more of a support question, but I couldn’t find any better place to ask. Please tell me if there is.

I don’t understand what is the proper way to retrieve relations on a single entity, that I got via $repo->findByPK(…).
I figured out I can do $repo->select()->wherePK(…)->load("country")->fetchOne(), but is that the "usual" way? I’m starting to understand that it’s not the entity’s job to "load things," so I guess it makes sense.

Also the docs (Basics > Simple Relation) uses type hints on the getter:

public function getAddress(): ?Address

But if I do that and use $repo->findByPK(…) and then call my getter, I get an error because the property contains a Cycle\ORM\Promise\Reference.

Can I do anything with this Reference class? It doesn’t seem to even contain the ID of the related entity.
Should I forget about type hints for relation accessors?
Should I forget about the findByPK method?

[wolfy-j]

Hi,

you can use findByPK method reliably only if you have installed the proxy extension (a.k.a. lazy loading entities). The Reference is default placeholder - you can use it to build new relations but you can't use it to access the entity data.

The recommended method is to fully isolate all loads into the repository, i.e. something like that:

$modelRepository->findWithSomeRelation($id);
$modelRepository->findWithSomeRelationComposition($id);

While lazy-load is legit method - it drastically complicates testing your application. Using a designated repository method is more time consuming, but it helps you to build proper abstraction for aggregate roots and makes mocking in tests much easier.

So the answer:

• Use Proxies if you want to keep using findByPK with lazy loaded entities
• Use specified repository method with load() inside to create proper encapsulation of select logic

In the ideal world, your domain code must not know anything about Select, but only about Repository (READ) and TransactionInterface (PERSIST).

[sylbru]

Thank you for this answer!

I just tried to use proxies, instanciating ORM\Promise\ProxyFactory thanks to the magic of my DI container, but it didn’t work because $instantiator was null, maybe because it defaults to null in the parameter list of the constructor? Removing = null there (https://github.com/cycle/proxy-factory/blob/master/src/Promise/ProxyFactory.php#L58) fixed it and allowed me to use lazy-loading, but obviously I won’t be working with a patch like this. So I guess I’m missing something concerning the instanciation of ProxyFactory.

But in the meantime I might as well try working with custom repository methods as you suggest. I guess it still doesn’t allow me to use typed properties, or type hints on the getters, right?

I feel like I will need to set up proxies in any case, this thing with the Promise\Reference instance in my property doesn’t feel right.

[sylbru]

I managed to instanciate ProxyFactory by letting my DI container (PHP-DI) retrieve the first three arguments:

function (
    ORM\Promise\Declaration\Extractor $extractor,
    ORM\Promise\Printer $printer,
    Doctrine\Instantiator\Instantiator $instantiator
) {
    ...

    $pf = new ORM\Promise\ProxyFactory($extractor, $printer, $instantiator);
    $orm = ...
        ->withPromiseFactory($pf);

    return $orm;
}

Does that look like a correct way to do it?

[wolfy-j]

This seems to be the correct way (@vvval , why do we allow the proxy factory to be initiated in broken mode?).

But in the meantime I might as well try working with custom repository methods as you suggest. I guess it still doesn’t allow me to use typed properties, or type hints on the getters, right?

It seems that for now - yes, it won't. But let's keep this ticket open, we might want to skip initialization of non loaded relations in future relations allowing you to use models without that side effect.

[sylbru]

Thanks so much for your help, I think I’m good to go for now!