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.
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.
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:
// 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.
I made a first pass at this: mridgway@20dc72e
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.
This was implemented by Michael, thank you!
Issue was closed with resolution "Fixed"