DDC-2224: convertToDatabaseValueSQL() is not honored for DQL query parameters #2798

New Issue

admin · 2026-01-22T14:03:58+01:00

admin commented

2026-01-22 14:03:58 +01:00

Originally created by @doctrinebot on GitHub (Jan 5, 2013).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user benjamin:

Following discussion on Google Groups:
https://groups.google.com/d/msg/doctrine-dev/-/gG-VGiAGQiMJ

When using a mapping type which declares convertToDatabaseValueSQL(), this method is not invoked when passing a value as parameter to a DQL query.

For example, if I declare a mapping type MyType:

class MyType extends \Doctrine\DBAL\Types\Type
{
    public function canRequireSQLConversion()
    {
        return true;
    }

    public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
    {
        return sprintf('FUNCTION(%s)', $sqlExpr);
    }

    // ...
}

And pass a parameter with this type to a DQL query:

$query = $em->createQuery('SELECT e FROM Entity e WHERE e.field = :field');
$query->setParameter('field', $value, 'MyType');

I would expect the following SQL to be generated:

SELECT ... WHERE ... = FUNCTION(?)

But the current SQL generated is the following:

SELECT ... WHERE ... = ?

Originally created by @doctrinebot on GitHub (Jan 5, 2013). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user benjamin: Following discussion on Google Groups: https://groups.google.com/d/msg/doctrine-dev/-/gG-VGiAGQiMJ When using a mapping type which declares `convertToDatabaseValueSQL()`, this method is not invoked when passing a value as parameter to a DQL query. For example, if I declare a mapping type `MyType`: ``` class MyType extends \Doctrine\DBAL\Types\Type { public function canRequireSQLConversion() { return true; } public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform) { return sprintf('FUNCTION(%s)', $sqlExpr); } // ... } ``` And pass a parameter with this type to a DQL query: ``` $query = $em->createQuery('SELECT e FROM Entity e WHERE e.field = :field'); $query->setParameter('field', $value, 'MyType'); ``` I would expect the following SQL to be generated: ``` SELECT ... WHERE ... = FUNCTION(?) ``` But the current SQL generated is the following: ``` SELECT ... WHERE ... = ? ```

admin added the Bug Invalid labels 2026-01-22 14:03:58 +01:00

admin closed this issue

2026-01-22 14:03:59 +01:00

admin commented

2026-01-22 14:03:59 +01:00

@doctrinebot commented on GitHub (Jan 5, 2013):

@doctrinebot commented on GitHub (Jan 5, 2013): - depends on [DDC-3625: [GH-1339] [DDC-2224] Honor convertToDatabaseValueSQL() in DQL query parameters](http://www.doctrine-project.org/jira/browse/DDC-3625) - duplicates [DDC-2240: Inconsistent querying for parameter type (from ClassMetadata) between using Find/FindBy and DoctrineQL](http://www.doctrine-project.org/jira/browse/DDC-2240)

admin commented

2026-01-22 14:04:00 +01:00

@doctrinebot commented on GitHub (Feb 8, 2013):

Comment created by mnapoli:

Fix proposal: https://github.com/doctrine/doctrine2/pull/574

@doctrinebot commented on GitHub (Feb 8, 2013): Comment created by mnapoli: Fix proposal: https://github.com/doctrine/doctrine2/pull/574

admin commented

2026-01-22 14:04:01 +01:00

@doctrinebot commented on GitHub (Feb 8, 2013):

Comment created by mnapoli:

It turns out convertToDatabaseValue() is not called as well.

For example:

class MyType extends \Doctrine\DBAL\Types\Type
{
    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        return serialize($value);
    }

    // ...
}

The SQL generated should not change, but the parameter should go through "convertToDatabaseValue", which is not the case.

@doctrinebot commented on GitHub (Feb 8, 2013): Comment created by mnapoli: It turns out convertToDatabaseValue() is not called as well. For example: ``` class MyType extends \Doctrine\DBAL\Types\Type { public function convertToDatabaseValue($value, AbstractPlatform $platform) { return serialize($value); } // ... } ``` The SQL generated should not change, but the parameter should go through "convertToDatabaseValue", which is not the case.

admin commented

2026-01-22 14:04:01 +01:00

@doctrinebot commented on GitHub (Feb 8, 2013):

Comment created by benjamin:

Have you passed the type as the third parameter to setParameter() ?
Because this works fine for me!

@doctrinebot commented on GitHub (Feb 8, 2013): Comment created by benjamin: Have you passed the type as the third parameter to setParameter() ? Because this works fine for me!

admin commented

2026-01-22 14:04:03 +01:00

@doctrinebot commented on GitHub (Feb 8, 2013):

Comment created by mnapoli:

You are right!

But shouldn't the Type mapping be taken into account anyway? I makes sense to me at least (a column has a type, when I specify a parameter for this column, it is for this type), but maybe that was just designed that way?

@doctrinebot commented on GitHub (Feb 8, 2013): Comment created by mnapoli: You are right! But shouldn't the Type mapping be taken into account anyway? I makes sense to me at least (a column has a type, when I specify a parameter for this column, it is for this type), but maybe that was just designed that way?

admin commented

2026-01-22 14:04:05 +01:00

@doctrinebot commented on GitHub (Feb 8, 2013):

Comment created by benjamin:

That would make sense, but I think that because of the flexibility of DQL, it's not always obvious what type you want to use.
Say you have some complex expression like:

WHERE entity.field = SomeDQLFunction(:value, entity.otherField)

Then we can't be sure what mapping type to use here (unless we can infer it from SomeDQLFunction, but this is yet another story).
Though I do agree that would be great to have the type inferred automatically when you do a simple:

WHERE entity.field = :value

Here, there's no ambiguity, and if entity.field has a custom mapping type, then I can't see a reason why it shouldn't be applied to the parameter by default.

@doctrinebot commented on GitHub (Feb 8, 2013): Comment created by benjamin: That would make sense, but I think that because of the flexibility of DQL, it's not always obvious what type you want to use. Say you have some complex expression like: ``` WHERE entity.field = SomeDQLFunction(:value, entity.otherField) ``` Then we can't be sure what mapping type to use here (unless we can infer it from `SomeDQLFunction`, but this is yet another story). Though I do agree that would be great to have the type inferred automatically when you do a simple: ``` WHERE entity.field = :value ``` Here, there's no ambiguity, and if `entity.field` has a custom mapping type, then I can't see a reason why it shouldn't be applied to the parameter by default.

admin commented

2026-01-22 14:04:05 +01:00

@doctrinebot commented on GitHub (Feb 8, 2013):

Comment created by mnapoli:

I made a failing test case, I'll see if I can work on that.

I will open a separate ticket for this.

Edit: http://www.doctrine-project.org/jira/browse/DDC-2290

@doctrinebot commented on GitHub (Feb 8, 2013): Comment created by mnapoli: I made a failing test case, I'll see if I can work on that. I will open a separate ticket for this. Edit: http://www.doctrine-project.org/jira/browse/[DDC-2290](http://www.doctrine-project.org/jira/browse/DDC-2290)

admin commented

2026-01-22 14:04:07 +01:00

@doctrinebot commented on GitHub (Apr 4, 2013):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Apr 4, 2013): Issue was closed with resolution "Invalid"

admin commented

2026-01-22 14:04:07 +01:00

@BenMorel commented on GitHub (May 26, 2016):

@beberlei @mnapoli I think this bug has been closed by mistake. Can you reopen it, or should I create a new one?

Three years later, it would be nice to fix this bug that regularly bites me!

@BenMorel commented on GitHub (May 26, 2016): @beberlei @mnapoli I think this bug has been closed by mistake. Can you reopen it, or should I create a new one? Three years later, it would be nice to fix this bug that regularly bites me!

admin commented

2026-01-22 14:04:07 +01:00

@Ocramius commented on GitHub (May 26, 2016):

I can re-open, but we'll need a test case

@Ocramius commented on GitHub (May 26, 2016): I can re-open, but we'll need a test case

admin commented

2026-01-22 14:04:07 +01:00

@BenMorel commented on GitHub (May 26, 2016):

@Ocramius While trying to create a test case, I realized that this bug has actually been fixed!
It is another bug I stumbled upon, in the Paginator. I will open another bug when I can produce a minimal test case. You can close this bug again, thank you!

@BenMorel commented on GitHub (May 26, 2016): @Ocramius While trying to create a test case, I realized that this bug has actually been fixed! It is another bug I stumbled upon, in the Paginator. I will open another bug when I can produce a minimal test case. You can close this bug again, thank you!

admin commented

2026-01-22 14:04:11 +01:00

@mnapoli commented on GitHub (May 26, 2016):

Well that was fast ;)

@mnapoli commented on GitHub (May 26, 2016): Well that was fast ;)

admin commented

2026-01-22 14:04:11 +01:00

@Ocramius commented on GitHub (May 26, 2016):

Aaaaand re-closing :-)

@Ocramius commented on GitHub (May 26, 2016): Aaaaand re-closing :-)

admin commented

2026-01-22 14:04:12 +01:00

@BenMorel commented on GitHub (May 26, 2016):

No time to lose ;-) Sorry for the confusion anyway. Reported as #5839.

@BenMorel commented on GitHub (May 26, 2016): No time to lose ;-) Sorry for the confusion anyway. Reported as #5839.

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#2798