Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      Building a ResultSetMapping yourself is tedious work, it can be simplified by passing ClassMetadata instances, so that the RSM even changes when the Entity Metadata changes.

      Two use-cases:

      1. Add Entity X as Root Entity
      2. Add Entity X as Fetch Joined Entity of parent entity Y

        Activity

        Hide
        Michael Ridgway added a comment -

        What are the inputs and outputs from this? Would this return just the ResultSetMap and then you'd be expected to generate the SQL yourself?

        The main reason for using the RSM is if you are trying to do something that is not supported in DQL. With the SQL query building functions being added to the DBAL, would it be better to have a helper that takes in DQL (or DQL parts?) and returns the SQL query and the RSM?

        I'm not sure if this covers all use cases, but probably the most common.

        Show
        Michael Ridgway added a comment - What are the inputs and outputs from this? Would this return just the ResultSetMap and then you'd be expected to generate the SQL yourself? The main reason for using the RSM is if you are trying to do something that is not supported in DQL. With the SQL query building functions being added to the DBAL, would it be better to have a helper that takes in DQL (or DQL parts?) and returns the SQL query and the RSM? I'm not sure if this covers all use cases, but probably the most common.
        Hide
        Benjamin Eberlei added a comment -

        I was thinking this accepts a ClassMetadata instance, or the EM + ClassName. Additionally you might need to pass a prefix when you have to build a query for many tables that have equally named columns:

        $rsm->addEntityColumnsFromClassMetadata($em->getClassMetadata('Article'));
        $rsm->addEntityColumnsFromClassMetadata($em->getClassMetadata('Category'), 'category_');
        // SELECT a.*, c.category_id, c.category_name, c.category_desc FROM Article a INNER JOIN Category c
        

        Naming and API is open to discussion obviously

        The goal should be that you dont have to change your native queries when you add or remove a column from your entity.

        Show
        Benjamin Eberlei added a comment - I was thinking this accepts a ClassMetadata instance, or the EM + ClassName. Additionally you might need to pass a prefix when you have to build a query for many tables that have equally named columns: $rsm->addEntityColumnsFromClassMetadata($em->getClassMetadata('Article')); $rsm->addEntityColumnsFromClassMetadata($em->getClassMetadata('Category'), 'category_'); // SELECT a.*, c.category_id, c.category_name, c.category_desc FROM Article a INNER JOIN Category c Naming and API is open to discussion obviously The goal should be that you dont have to change your native queries when you add or remove a column from your entity.
        Hide
        Michael Ridgway added a comment -

        I made a first pass at this: https://github.com/mridgway/doctrine2/commit/20dc72ef9ae0d7c4afead35c249c224b95570aa7

        This basically creates new functions with the same functionality as addEntityResult and addJoinedEntityResult except that they take in ClassMetadata and will add the fields from the class automatically. There is also an additional parameter for each function that is a prefix that is added to the entity's column name (see test case for example).

        One problem with this implementation is that it doesn't use DBAL\Platforms\AbstractPlatform::getSQLResultCasing since we don't have access to the connection.

        There are probably other problems, but I wanted to get some feedback on whether this is heading in the right direction.

        Show
        Michael Ridgway added a comment - I made a first pass at this: https://github.com/mridgway/doctrine2/commit/20dc72ef9ae0d7c4afead35c249c224b95570aa7 This basically creates new functions with the same functionality as addEntityResult and addJoinedEntityResult except that they take in ClassMetadata and will add the fields from the class automatically. There is also an additional parameter for each function that is a prefix that is added to the entity's column name (see test case for example). One problem with this implementation is that it doesn't use DBAL\Platforms\AbstractPlatform::getSQLResultCasing since we don't have access to the connection. There are probably other problems, but I wanted to get some feedback on whether this is heading in the right direction.
        Hide
        Benjamin Eberlei added a comment -

        This was implemented by Michael, thank you!

        Show
        Benjamin Eberlei added a comment - This was implemented by Michael, thank you!

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Benjamin Eberlei
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: