DDC-1851: relationships are not error checked #2331

New Issue

admin · 2026-01-22T13:48:43+01:00

admin commented

2026-01-22 13:48:43 +01:00

Originally created by @doctrinebot on GitHub (May 31, 2012).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user peytonrm:

Consider class A having a many-to-one relationship with B. In the database A's b_id column is zero or references a row of B that has been deleted.

When using lazy-loading, $a->getB()->getName() will throw EntityNotFoundException. $a->getB() will not be NULL, but rather a proxy (the b_id column was not NULL). So, to safely use $a->getB()->getName() in a view, you have to both wrap it in a try block and check for null (for "Fatal error: Call to a member function") in the view.

That situation is really tricky because Doctrine can't know B is NULL until the proxy's **load() is called. It would then need to convert the Proxy object to NULL and have all the calling functions handle that gracefully.

So what I'd really like is some reasonable way to convert invalid relationships to NULL without bloating every traversal call. Lazy loading makes handling invalid relationships inside the model very difficult because of **load() timing.

This is a major issue for us because potentially every traversal call in our application could trigger this problem.

Originally created by @doctrinebot on GitHub (May 31, 2012). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user peytonrm: Consider class A having a many-to-one relationship with B. In the database A's b_id column is zero or references a row of B that has been deleted. When using lazy-loading, $a->getB()->getName() will throw EntityNotFoundException. $a->getB() will not be NULL, but rather a proxy (the b_id column was not NULL). So, to safely use $a->getB()->getName() in a view, you have to **both** wrap it in a try block and check for null (for "Fatal error: Call to a member function") in the view. That situation is really tricky because Doctrine can't know B is NULL until the proxy's **load() is called. It would then need to convert the Proxy object to NULL and have all the calling functions handle that gracefully. So what I'd really like is some reasonable way to convert invalid relationships to NULL without bloating every traversal call. Lazy loading makes handling invalid relationships inside the model very difficult because of **load() timing. This is a major issue for us because potentially every traversal call in our application could trigger this problem.

admin added the Bug label 2026-01-22 13:48:43 +01:00

admin closed this issue

2026-01-22 13:48:43 +01:00

admin commented

2026-01-22 13:48:44 +01:00

@doctrinebot commented on GitHub (Jun 8, 2012):

Comment created by @ocramius:

Don't really get your point right now: you have an inconsistent object graph and are trying to traverse it through relations? This is exactly the use case for foreign keys and cascading at db level, while traversing the graph through your getters and properties is completely up to you...

I don't think it is anything the ORM should handle for you, as you have to be aware of your entities being basically broken by the schema itself.

@doctrinebot commented on GitHub (Jun 8, 2012): Comment created by @ocramius: Don't really get your point right now: you have an inconsistent object graph and are trying to traverse it through relations? This is exactly the use case for foreign keys and cascading at db level, while traversing the graph through your getters and properties is completely up to you... I don't think it is anything the ORM should handle for you, as you have to be aware of your entities being basically broken by the schema itself.

admin commented

2026-01-22 13:48:45 +01:00

@doctrinebot commented on GitHub (Jun 11, 2012):

Comment created by peytonrm:

We have several hundred tables without foreign keys, so going back and adding them is not really financially reasonable at this point. We will also need to do sharding at some point, so we do not wish to use foreign keys anyway. I'm not asking for the ORM to fix the data or anything like that, I would just like if it would return null instead of throwing exceptions. This would make all of our traversal calls much cleaner than having to do try/catch all over the place.

@doctrinebot commented on GitHub (Jun 11, 2012): Comment created by peytonrm: We have several hundred tables without foreign keys, so going back and adding them is not really financially reasonable at this point. We will also need to do sharding at some point, so we do not wish to use foreign keys anyway. I'm not asking for the ORM to fix the data or anything like that, I would just like if it would return null instead of throwing exceptions. This would make all of our traversal calls much cleaner than having to do try/catch all over the place.

admin commented

2026-01-22 13:48:46 +01:00

@doctrinebot commented on GitHub (Jul 5, 2012):

Comment created by @beberlei:

You can wrap the access to proxies yourself in getters, for this you can overwrite EntityGenerator get template, or do this yourself:

public function getRelated()
{
    if ($this->related->getId() == 0) {
        return null;
    }

     if ($this->related instanceof Proxy) {
        try {
               $this->related->**load();
         } catch(\Exception $e) {
             return null;
         }
    }

    return $this->related;
}

Doctrine relies on the consistency of your data and we won't change the core to accompany for this kind of legacy database schema. How about cleaning up your database schema?

@doctrinebot commented on GitHub (Jul 5, 2012): Comment created by @beberlei: You can wrap the access to proxies yourself in getters, for this you can overwrite EntityGenerator get<method> template, or do this yourself: ``` public function getRelated() { if ($this->related->getId() == 0) { return null; } if ($this->related instanceof Proxy) { try { $this->related->**load(); } catch(\Exception $e) { return null; } } return $this->related; } ``` Doctrine relies on the consistency of your data and we won't change the core to accompany for this kind of legacy database schema. How about cleaning up your database schema?

admin commented

2026-01-22 13:48:46 +01:00

@doctrinebot commented on GitHub (Jul 5, 2012):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Jul 5, 2012): Issue was closed with resolution "Invalid"

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