Doctrine DBAL
  1. Doctrine DBAL
  2. DBAL-864

Failure to insert FALSE into a bool column

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      I have experienced this problem with MySQL, I am not sure how it behaves with other platforms. Also, maybe this duplicates http://www.doctrine-project.org/jira/browse/DBAL-630 but since that issue is specifically about PostreSQL I am creating a separate one.

      [Doctrine\DBAL\Exception\DriverException]
      An exception occurred while executing 'INSERT INTO ACL_Authorization
      (role_id, securityIdentity_id, parentAuthorization_id, entity_class, entity_id, cascadable)
      VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'
      with params [2, 2, null, "Account\\Domain\\Account", 2, false]:
      
      SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'cascadable' at row 1
      

      I think it's related to https://bugs.php.net/bug.php?id=49255 (PDO fails to insert boolean FALSE to MySQL in prepared statement) which casts FALSE into an empty string.

        Activity

        Hide
        Doctrine Bot added a comment -

        A related Github Pull-Request [GH-564] was closed:
        https://github.com/doctrine/dbal/pull/564

        Show
        Doctrine Bot added a comment - A related Github Pull-Request [GH-564] was closed: https://github.com/doctrine/dbal/pull/564
        Hide
        Steve Müller added a comment -

        Closing this issue for now.

        Show
        Steve Müller added a comment - Closing this issue for now.
        Hide
        Steve Müller added a comment -

        I share your opinion to some extent. But this task is not as trivial as it seems. Especially when it comes to provide an implementation that behaves the same on all vendors, platforms and versions.
        You might want to look at this: http://www.doctrine-project.org/jira/browse/DBAL-630 just to get an idea what a mess this is.

        Show
        Steve Müller added a comment - I share your opinion to some extent. But this task is not as trivial as it seems. Especially when it comes to provide an implementation that behaves the same on all vendors, platforms and versions. You might want to look at this: http://www.doctrine-project.org/jira/browse/DBAL-630 just to get an idea what a mess this is.
        Hide
        Matthieu Napoli added a comment -

        > Hope this helps.

        Yes it does, I still have mixed feelings about this but it makes sense (and I didn't think about custom types). Thanks.

        Show
        Matthieu Napoli added a comment - > Hope this helps. Yes it does, I still have mixed feelings about this but it makes sense (and I didn't think about custom types). Thanks.
        Hide
        Steve Müller added a comment - - edited

        I get what you mean but what you want is just to magic at that level I suppose. Connection::insert() is at a very low level and mainly just a wrapper around a prepared statement. How would you expect this method to find out the correct DBAL type? Checking each value's PHP type and evaluate the appropriate DBAL type? First off this would add a lot of performance overhead and does not ensure that the correct binding type is used in the end. Imagine that you can also have custom DBAL types with custom binding information and data conversion.
        Just do something like this:

        $connection->insert('some_table', array('some_column' => false), array('some_column' => 'boolean'));
        

        Basically in the third argument you define the DBAL type name mapping which converts the value appropriately for the underlying platform and chooses the correct PARAM binding type.

        In the end there is a reason why PDO doesn't have this kind of magic either and adding a type abstraction layer that is platform independant on top of it makes it even more difficult to do what you would expect.
        Hope this helps.

        Show
        Steve Müller added a comment - - edited I get what you mean but what you want is just to magic at that level I suppose. Connection::insert() is at a very low level and mainly just a wrapper around a prepared statement. How would you expect this method to find out the correct DBAL type? Checking each value's PHP type and evaluate the appropriate DBAL type? First off this would add a lot of performance overhead and does not ensure that the correct binding type is used in the end. Imagine that you can also have custom DBAL types with custom binding information and data conversion. Just do something like this: $connection->insert('some_table', array('some_column' => false ), array('some_column' => ' boolean ')); Basically in the third argument you define the DBAL type name mapping which converts the value appropriately for the underlying platform and chooses the correct PARAM binding type. In the end there is a reason why PDO doesn't have this kind of magic either and adding a type abstraction layer that is platform independant on top of it makes it even more difficult to do what you would expect. Hope this helps.

          People

          • Assignee:
            Steve Müller
            Reporter:
            Matthieu Napoli
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: