Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2763

Inheritance. CTI & STI. Improve lazy load associated entity, when target entity in association mapping is not last leaf in class hierarchy.

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:

      Description

      If we look inside documentation, we can see this:

      There is a general performance consideration with Class Table Inheritance: If the target-entity of a many-to-one or one-to-one association is a CTI entity, it is preferable for performance reasons that it be a leaf entity in the inheritance hierarchy, (ie. have no subclasses). Otherwise Doctrine CANNOT create proxy instances of this entity and will ALWAYS load the entity eagerly.

      I think it can be improved, if we will load only discriminator column value for resolve target class name, instead of loading whole entity. When we perform query from root entity, dicriminator value is already present in fetched database row.
      What do you think?

        Activity

        Hide
        Marco Pivetta added a comment -

        Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know).

        What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI

        Show
        Marco Pivetta added a comment - Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know). What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI
        Hide
        Artur Eshenbrener added a comment -

        Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know).

        Of course, but fetching the discriminator value will produce less overhead than loading whole entity (with recursive loading joined entities). And, when you querying from root entity (with mapped sicriminator column), discriminator value already present in db result row (no need to extra query for dicriminator value).

        What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI

        The result of my proposal will ability to get proxy class without loading whole entity.

        Show
        Artur Eshenbrener added a comment - Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know). Of course, but fetching the discriminator value will produce less overhead than loading whole entity (with recursive loading joined entities). And, when you querying from root entity (with mapped sicriminator column), discriminator value already present in db result row (no need to extra query for dicriminator value). What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI The result of my proposal will ability to get proxy class without loading whole entity.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Artur Eshenbrener
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: