php – Doctrine DQL, class table inheritance and access to subclass fields-ThrowExceptions

Exception or error:

I have a problem with a DQL query and entity specialization.

I have an Entity called Auction, which is OneToOne relation with Item. Item is a mappedSuperclass for Film and Book. I need a query that could back a search engine, allowing the user to look for auctions with different properties AND selling items with different properties (it is the AND part that makes it challenging).

The problem is that even though Auction has an association pointing to Item as such, I need to have access to Film– and Book-specific fields. The users will specify the Item type they’re looking for, but I don’t see any way of using this information other than using INSTANCE OF in my DQL query.

So far, I have tried using a query like:

SELECT a FROM Entities\Auction a
    INNER JOIN a.item i 
    INNER JOIN i.bookTypes b 
    WHERE i INSTANCE OF Entities\Book 
    AND b.type = 'Fantasy' 
    AND ...". 

Such a query results in an error saying that:

Class Entities\Item has no field or association named bookTypes

which is false for Book, yet true for Item.

I have also tried

SELECT a FROM Entities\Book i 
    INNER JOIN a ...

but I reckon Doctrine requires that I refer to the same Entity in SELECT and FROM statements.

If that’s of importance, I am using class table inheritance. Still, I don’t think switching to single table inheritance would do the trick.

Any ideas?

How to solve:

As Matt stated, this is an old issue that Doctrine Project won’t fix (DDC-16).

The problem is that doctrine’s DQL is a statically typed language that comes with a certain amount of complexity in its internals.

We thought about allowing upcasting a couple of times, but the effort to get that working is simply not worth it, and people would simply abuse the syntax doing very dangerous things.

As stated on DDC-16, it is also indeed not possible to understand which class the property belongs to without incurring in nasty problems such as multiple subclasses defining same properties with different column names.

If you want to filter data in subclasses in a CTI or JTI, you may use the technique that I’ve described at . That couples your DQL with all involved subclasses.

The DQL you would need in your case is most probably (assuming that Entities\Book is a subclass of Entities\Item):

    Entities\Auction a 
    a.item i
    i.bookTypes b
            Entities\Book b
            b.type = 'Fantasy'

That is the pseudo-code for your problem. It is not nice, but keep in mind that SQL and DQL are very different and follow different rules.



I’ve discovered a solution for this. See my answer for this related question:

Doctrine2: Polymorphic Queries: Searching on properties of subclasses


You can easily solve this by left-joining your base entity with your inheritance class using the id:

SELECT a FROM Entities\Auction a
    INNER JOIN a.item i 
    INNER JOIN Entities\Book b WITH = 
    INNER JOIN b.bookTypes bt
    WHERE bt.type = 'Fantasy' 

or with a queryBuilder:

   ->from('Entities\Auction', 'a')
   ->innerJoin('a.item', 'i')
   ->innerJoin('Entities\Book', 'b', 'WITH', ' =')
   ->innerJoin('b.bookTypes', 'bt')
   ->where('bt.type = :type')
   ->setParameter('type', 'Fantasy');

This is based on the answer given by Ian Philips in the question here


The Doctrine team has stated that they’re not going to add support for this:

Pertinent comments from that page:

Thats indeed tricky. That syntax alone can, however, never work,
because there might be several subclasses that have a field named “d”,
so Doctrine would not know which field you mean.

I am closing this one.

The requirement of this issue is basically violating OO principles.

If you really need to filter across multiple child-entities in your
inheritance, then try something as following instead:

Root r WHERE IN (
Child c
c.field = :value


I had the same issue, and didn’t find a solution without using separate queries for each subclass and merging them later on the application level.

One thing I’m sure, single table inheritance will not solve this, completely the same thing.

There is another alternative, although being logically dirty.
Define all the fields (the ones you need) in the superclass. If the record logically doesn’t have that field it will be empty. Not a pretty sight, but hey, more optimized than 2-3-4-… queries. Also in this scenario single table inheritance is definitely the better way to go

Leave a Reply

Your email address will not be published. Required fields are marked *