[Question] Is there a way to infer custom parameter type automatically? #5581

New Issue

admin · 2026-01-22T15:11:50+01:00

admin commented

2026-01-22 15:11:50 +01:00

Originally created by @aledelgo on GitHub (Jun 20, 2017).

Originally assigned to: @Ocramius on GitHub.

Scraping the code i've noticed that it is about impossible to change the implementation of
ParameterTypeInferer with own custom code.
It seems to me impossible also to change the setParameter function of class Query because it is declared final.
The problem is i want to automatically infer my custom type when the value of a parameter is an instance of a certain class.
To be precise, i'm in Laravel and i'm using extensions to use the Carbon type.
I've a custom Carbon type that take in consideration the timezone of the date value and convert it to UTC (or the default timezone set in the config) in the convertToDatabaseValue function.

If in the queries i don't set the parameter type, the value (a Carbon instance) will be detected as a Datetime instance and my custom 'toUTC' conversion will never happen (convertToDatabaseValue never called). If i explicitly set the type of parameter with "CustomCarbonDatetimeType", my convertToDatabaseValue is called and the conversion to UTC works fine!

Now, as my entire system works with datetime only in UTC and (as many systems do) , don't store the timezone information in the DB considering all values to be in the same (UTC) timezone, i would like that wherever i use a Carbon instance as parameter value, the inferred parameter type should be "CustomCarbonDatetimeType".

Is there an elegant, not too much disrupting, way to do this?

Thanks

Originally created by @aledelgo on GitHub (Jun 20, 2017). Originally assigned to: @Ocramius on GitHub. Scraping the code i've noticed that it is about impossible to change the implementation of `ParameterTypeInferer` with own custom code. It seems to me impossible also to change the `setParameter` function of class Query because it is declared _final._ The problem is i want to automatically infer my custom type when the value of a parameter is an instance of a certain class. To be precise, i'm in Laravel and i'm using extensions to use the _Carbon_ type. I've a custom Carbon type that take in consideration the timezone of the date value and convert it to UTC (or the default timezone set in the config) in the `convertToDatabaseValue` function. If in the queries i don't set the parameter type, the value (a Carbon instance) will be detected as a _Datetime_ instance and my custom 'toUTC' conversion will never happen (convertToDatabaseValue never called). If i explicitly set the type of parameter with _"CustomCarbonDatetimeType"_, my `convertToDatabaseValue` is called and the conversion to UTC works fine! Now, as my entire system works with datetime only in UTC and (as many systems do) , don't store the timezone information in the DB considering all values to be in the same (UTC) timezone, i would like that wherever i use a Carbon instance as parameter value, the inferred parameter type should be "CustomCarbonDatetimeType". Is there an elegant, not too much disrupting, way to do this? Thanks

admin added the Won't Fix Question labels 2026-01-22 15:11:50 +01:00

admin closed this issue

2026-01-22 15:11:51 +01:00

admin commented

2026-01-22 15:11:52 +01:00

@Ocramius commented on GitHub (Jun 20, 2017):

Is there a way to infer custom parameter type automatically?

No, it's not designed to support that.

Pass in the type explicitly.

@Ocramius commented on GitHub (Jun 20, 2017): > Is there a way to infer custom parameter type automatically? No, it's not designed to support that. Pass in the type explicitly.

admin commented

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

@Ocramius commented on GitHub (Jun 20, 2017):

See also https://github.com/doctrine/doctrine2/issues/6443

@Ocramius commented on GitHub (Jun 20, 2017): See also https://github.com/doctrine/doctrine2/issues/6443

admin commented

2026-01-22 15:11:55 +01:00

@aledelgo commented on GitHub (Jun 20, 2017):

ok, thanks!

@aledelgo commented on GitHub (Jun 20, 2017): ok, thanks!

Sign in to join this conversation.