Roman S. Borschel
added a comment - 31/Mar/10 2:09 PM 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.
We might need special syntax for such constructs but I'm not sure it is worth it. If anyone has an idea, just shoot.
Alternatively, apart from using a native query, what about this DQL:
select a from A a where a.id not in (select c.id from C c where c.d = 2)

It is just not wise to deny a feature just because it violates OO principles when this is the only method.

We are working on an ORM (Object-Relational-Mapper), therefore Object-Orientation is first-class citizen and prioritized over everything else in the ORM.

There are usecases, when we have nothing to do.

There are use-cases for everything, but that doesn't mean that they should clutter the tool. This does not only apply to Doctrine ORM. An edge case functionality that has multiple workarounds and that cannot be implemented correctly within the tool does NOT need to land in the tool.

I provided a workaround that respects the OO and ORM rules and works also with the OO paradigm. Here is a pseudo-code description of what the DQL I pasted above does:

select all objects that are instance of Child by $someCriteria

select all objects that are instance of Root

iterate over Root instances and filter out those that are not in the results of the first selection

We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

Yes you can: there's SQL. SQL is a "structured query language" that is weakly typed and allows this sort of operation natively. This is a problem of the SQL domain, and it should be solved with SQL whenever the DQL becomes too complex/limited. Don't try to stuff a feature that is only possible in the SQL domain into DQL just because they look similar.
They are not the same thing.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

We are not ignoring the problem: we just point you to the right scope/tools to solve it. DQL has one way of solving it, which may or may not be viable to you. SQL has another way of solving this same problem, and it's not going to be implemented in DQL because DQL is statically typed, and upcasts and type juggling are not going to land in DQL.

Marco Pivetta
added a comment - 17/Jul/14 1:16 PM It is just not wise to deny a feature just because it violates OO principles when this is the only method.
We are working on an ORM (Object-Relational-Mapper), therefore Object-Orientation is first-class citizen and prioritized over everything else in the ORM.
There are usecases, when we have nothing to do.
There are use-cases for everything, but that doesn't mean that they should clutter the tool. This does not only apply to Doctrine ORM. An edge case functionality that has multiple workarounds and that cannot be implemented correctly within the tool does NOT need to land in the tool.
I provided a workaround that respects the OO and ORM rules and works also with the OO paradigm. Here is a pseudo-code description of what the DQL I pasted above does:
select all objects that are instance of Child by $someCriteria
select all objects that are instance of Root
iterate over Root instances and filter out those that are not in the results of the first selection
We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.
Yes you can: there's SQL. SQL is a "structured query language" that is weakly typed and allows this sort of operation natively. This is a problem of the SQL domain, and it should be solved with SQL whenever the DQL becomes too complex/limited. Don't try to stuff a feature that is only possible in the SQL domain into DQL just because they look similar.
They are not the same thing.
This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.
We are not ignoring the problem: we just point you to the right scope/tools to solve it. DQL has one way of solving it, which may or may not be viable to you. SQL has another way of solving this same problem, and it's not going to be implemented in DQL because DQL is statically typed, and upcasts and type juggling are not going to land in DQL.

Marco Pivetta
added a comment - 17/Jul/14 2:21 PM Bogdan Yurov we already tried looking into this multiple times.
The only "clean-ish" solution would be to support upcasting somehow, and the effort and complexity derived from it is not worth it.

@ocramius
What about "CAST()" construction? You were talking about OO, but there are some languages, that could argue with you.

For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?

Bogdan Yurov
added a comment - 17/Jul/14 2:37 PM @ocramius
What about "CAST()" construction? You were talking about OO, but there are some languages, that could argue with you.
For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?