Integrate TypedExpression::getReturnType into FunctionNode by default #7569

New Issue

2026-01-22T15:53:39+01:00

admin commented

2026-01-22 15:53:39 +01:00

Originally created by @beberlei on GitHub (Nov 5, 2025).

Let all function nodes return a specific type, which was added as optional feature to DQL functions in https://github.com/doctrine/orm/commit/24e9a7caaf8f2c02b33c3573486bd0ecfd8fa4a0.

This should be done in a way where users are forced to implement getReturnType, because otherwise people will keep returning the values as "string" from their custom dQL when used in scalar context.

Using a Query Hint, we can make this opt-in in ORM 3 and opt-out in ORM 4. Since we have default query hints, users can use this as a global switch and setting. $config->setDefaultQueryHints([Query::FORCE_SCALAR_TYPE_CONVERSION => true]); or FORCE_SCALAR_TYPE_AS_STRINGS => true.

Originally created by @beberlei on GitHub (Nov 5, 2025). Let all function nodes return a specific type, which was added as optional feature to DQL functions in https://github.com/doctrine/orm/commit/24e9a7caaf8f2c02b33c3573486bd0ecfd8fa4a0. This should be done in a way where users are forced to implement getReturnType, because otherwise people will keep returning the values as "string" from their custom dQL when used in scalar context. Using a Query Hint, we can make this opt-in in ORM 3 and opt-out in ORM 4. Since we have default query hints, users can use this as a global switch and setting. `$config->setDefaultQueryHints([Query::FORCE_SCALAR_TYPE_CONVERSION => true]);` or `FORCE_SCALAR_TYPE_AS_STRINGS => true`.

admin added the Improvement Deprecation labels 2026-01-22 15:53:39 +01:00

admin commented

2026-01-22 15:53:39 +01:00

@greg0ire commented on GitHub (Nov 6, 2025):

Regarding the constant, should it maybe mention functions and dql? Also, why mention scalar? We could name it CONVERT_DQL_FUNCTION_RETURN_TYPE for instance.

@greg0ire commented on GitHub (Nov 6, 2025): Regarding the constant, should it maybe mention functions and dql? Also, why mention scalar? We could name it `CONVERT_DQL_FUNCTION_RETURN_TYPE` for instance.

admin commented

2026-01-22 15:53:39 +01:00

@stof commented on GitHub (Jan 6, 2026):

shouldn't we always trigger a deprecation warning when registering a custom function that does not implement TypedExpression in ORM 3.x (we could perform the check at the configuration time to trigger it once per registered function instead of triggering it on usage).
I don't see the need for a query hint to opt-in or opt-out from the deprecation for specific queries.

And in 4.0, I would make FunctionNode implement TypedExpression directly, which will force all its concrete child classes to implement the method of the interface.

@stof commented on GitHub (Jan 6, 2026): shouldn't we always trigger a deprecation warning when registering a custom function that does not implement `TypedExpression` in ORM 3.x (we could perform the check at the configuration time to trigger it once per registered function instead of triggering it on usage). I don't see the need for a query hint to opt-in or opt-out from the deprecation for specific queries. And in 4.0, I would make `FunctionNode` implement `TypedExpression` directly, which will force all its concrete child classes to implement the method of the interface.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7569