DDC-1059: Add helper for ResultSetMapping #1324

New Issue

admin · 2026-01-22T13:10:23+01:00

admin commented

2026-01-22 13:10:23 +01:00

Originally created by @doctrinebot on GitHub (Mar 5, 2011).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user @beberlei:

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:

Add Entity X as Root Entity
Add Entity X as Fetch Joined Entity of parent entity Y

Originally created by @doctrinebot on GitHub (Mar 5, 2011). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user @beberlei: 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

admin added the New Feature label 2026-01-22 13:10:23 +01:00

admin closed this issue

2026-01-22 13:10:24 +01:00

admin commented

2026-01-22 13:10:25 +01:00

@doctrinebot commented on GitHub (Mar 24, 2011):

Comment created by mridgway:

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.

@doctrinebot commented on GitHub (Mar 24, 2011): Comment created by mridgway: 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.

admin commented

2026-01-22 13:10:26 +01:00

@doctrinebot commented on GitHub (Mar 25, 2011):

Comment created by @beberlei:

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.

@doctrinebot commented on GitHub (Mar 25, 2011): Comment created by @beberlei: 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.

admin commented

2026-01-22 13:10:26 +01:00

@doctrinebot commented on GitHub (Mar 29, 2011):

Comment created by mridgway:

I made a first pass at this: 20dc72ef9a

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.

@doctrinebot commented on GitHub (Mar 29, 2011): Comment created by mridgway: 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.

admin commented

2026-01-22 13:10:28 +01:00

@doctrinebot commented on GitHub (May 15, 2011):

Comment created by @beberlei:

This was implemented by Michael, thank you!

@doctrinebot commented on GitHub (May 15, 2011): Comment created by @beberlei: This was implemented by Michael, thank you!

admin commented

2026-01-22 13:10:28 +01:00

@doctrinebot commented on GitHub (May 15, 2011):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (May 15, 2011): Issue was closed with resolution "Fixed"

admin referenced this issue