Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-16

DQL Ignores properties of subclasses

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.0-ALPHA2
    • Fix Version/s: None
    • Component/s: DQL
    • Security Level: All
    • Labels:
      None

      Description

      I have a classes B and C which inherit from superclass A. I would like
      to get a list of all A's but filter the list to ignore those in C
      which have a property d set to 2.

      select a from A where a.d == 2 fails because "d" is not a property of A.

        Issue Links

          Activity

          Hide
          Marco Pivetta added a comment -

          Bogdan Yurov I think Guilherme Blanco is thinking of providing a cast syntax.

          Show
          Marco Pivetta added a comment - Bogdan Yurov I think Guilherme Blanco is thinking of providing a cast syntax.
          Hide
          Bogdan Yurov added a comment -

          @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?

          Show
          Bogdan Yurov added a comment - @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?
          Hide
          Marco Pivetta added a comment -

          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.

          Show
          Marco Pivetta added a comment - 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.
          Hide
          Bogdan Yurov added a comment -

          If we provide a workaround, is there any way to merge it to master branch? What we can do to vote up this feature?

          Show
          Bogdan Yurov added a comment - If we provide a workaround, is there any way to merge it to master branch? What we can do to vote up this feature?
          Hide
          Marco Pivetta added a comment -

          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.

          Show
          Marco Pivetta added a comment - 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.

            People

            • Assignee:
              Marco Pivetta
              Reporter:
              Avi Block
            • Votes:
              6 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: