TypeError: StatementWrapper::bindValue(): Argument #3 ($dataType) must be of type int #1966
Comments
|
Seems like the type of the |
|
Hi! thanks for the fast reply. and the relative SQL part: Thank you |
|
Hmm, hard to say where this could go wrong. It's a varchar column... In your output, you can see that This should be an int indicating the parameter type to PDO (2 for a string parameter). The value is retrieved from the table map file describing your Settings table (aptly called and the Let me know how it goes |
|
I'll try asap and let you know, thank you! |
|
Hi, |
|
Hello, Note: After a deeper analysis of the logs, I saw the 90% of the occurrences were related to the update of an INT column with an Integer value. But not all the times we declared that value as INT, sometimes it was implicitly casted to INT by PHP. I don't think this could be related, but still "90%" would be a big coincidence. |
|
Hello, The only infos I can add: Maybe propel has a local cache within the pod? It gets corrupted and restarting the pod, problem is solved? This issue is getting critical for us, considering that happens in production envs. Thanks in advance |
|
Hmm, curios. The type id that shouldn't be null is retrieved from the column map in /Propel/Runtime/Adapter/Pdo/MysqlAdapter::bindValue(). The type identifier stored in the ColumnMap is turned into the PDO id through a lookup in \Propel\Generator\Model\PropelTypes. The values are hard-coded into files, either from model:build or Propel directly. If the type identifier from the column map does not exist in the lookup array in PropelTypes, you should get an "Undefined array key" warning, but this is likely disabled on prod. So from a distance, this is the most likely candidate for an error, maybe something weird in opcache? Since the error occurs indeterminately, I would start by finding out what the ColumnMap looks like when the error happens. So I would change the Propel file manually (yes, changing a library file per hand, desperate measures...): public function bindValue(StatementInterface $stmt, string $parameter, $value, ColumnMap $cMap, ?int $position = null): bool
{
$pdoType = $cMap->getPdoType(); // <---- should not return null
if ($pdoType === null){
$reflector = new \ReflectionClass(get_class($cMap->getTable()));
$vals = [
'map file' => $reflector->getFileName(),
'column' => $cMap->getFullyQualifiedName(),
'type' => $cMap->getType(),
];
// then log or throw $vals
}Also, getting to the lookup table in PropelTypes would be interesting. Let me know if you find anything. |
|
Hello, Thank you for your help! |
|
Oh, disabling opcache will ruin performance. Even if the problem comes from there, just disabling it will not work as solution. As a workaround, you are probably better off reloading the whole page. |
|
Hi, Let us know if you find any confirmed relation with opcache, and eventually if there is a fix. Thank you! |
|
Very interesting. Huzzah, I guess, problem found. That would mean that the classes read from opcache behave differently than what was put in. I don't think that this is related to Propel, particularly when the issue is non-deterministic. Very likely, the problem comes from the PHP setup in the pods. But let me know what you find. |
Hello,
we are lately facing this error in different K8S environments serving a PHP API that use Propel ORM:
The problem is not related to this table only, but to "random" tables, in "random" queries.
With random I mean: every time it occur in different tables and queries.. I still didn't find a way to reproduce it.
I noticed though, that after restarting the API pod, the problem disappear for a while and generally appears again after the next deploy of the API.
So maybe there is a thing with K8S, but I can't get what.
Versions:
Thanks in advance!
Full stack trace:
The text was updated successfully, but these errors were encountered: