Closed TheUnableDeveloper closed 1 month ago
Seems like the type of the id
column is not recognized. Can you add the definition of the settings table in schema.xml?
Hi! thanks for the fast reply. Here it is the schema.xml table definition:
<table name="settings" idMethod="native" phpName="Settings">
<column name="id" phpName="Id" type="VARCHAR" size="50" primaryKey="true" required="true"/>
<column name="setting_value" phpName="SettingValue" type="LONGVARCHAR" required="true"/>
<vendor type="mysql">
<parameter name="Engine" value="InnoDB"/>
</vendor>
</table>
and the relative SQL part:
DROP TABLE IF EXISTS "settings";
CREATE TABLE "settings"
(
"id" VARCHAR(50) NOT NULL,
"setting_value" TEXT NOT NULL,
PRIMARY KEY ("id")
) ENGINE=InnoDB;
Thank you
Hmm, hard to say where this could go wrong. It's a varchar column...
In your output, you can see that bindValue()
is called with NULL as third parameter:
StatementWrapper->bindValue(':p1', 'attachment_vali...', NULL)
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 SettingsTableMap.php
), which should contain a line like
$this->addPrimaryKey('id', 'Id', 'VARCHAR', true, 50, null);
and the VARCHAR
value there should make Propel figure out the type of the parameter. You can check if the line is there, but one way or another, I would start by rebuilding the model files (which also rebuilds table maps) with the propel model:build
command. If that doesn't work, try to update Propel. Otherwise, I have no idea what could go wrong.
Let me know how it goes
I'll try asap and let you know, thank you!
Hi, I'm back. I tried to run the build command, though the problem was hard to replicate before (and now too) so it'll take a while to check the solution. In the meantime I'll plan a full upgrade of the orm. Thank you for your time!
Hello, We upgraded to the last version of Propel and we didn't face the issue anymore, lately. So I believe we can close the issue. Thank for your support.
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, after some weeks without any problems , we lately faced this problem again. Always on different tables and with different kind of queries (SELECT, UPDATE etc).
The only infos I can add: 1) propel version: 2.0.0-beta3 2) server type: Apache on kubernetes pods (image: php:8.1.14RC1-apache-buster) 3) we are still not able to reproduce the error in our test or dev envs 4) most of the times that we face this problem, it disappear if we restart the pod.
Maybe propel has a local cache within the pod? It gets corrupted and restarting the pod, problem is solved? But this would be an effect of a prior bug.
This issue is getting critical for us, considering that happens in production envs. What can I do to help debugging?
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, I confirm that we use opCache, we will try to disable it. In the meantime I'll check the files you mentioned and I'll be back to you.
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, we disabled opcache in order to make a test and the problem immediately disappeared. We'll keep it monitored, and the app doesn't seem that much slower so, at the moment, we'll proceed in this way.
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 fixed the issue. It was related to a wrong OPCACHE setup.
This is our new setup:
[opcache]
opcache.enable=1
opcache.revalidate_freq=1000
opcache.validate_timestamps=0
opcache.max_accelerated_files=100000
opcache.memory_consumption=256
opcache.max_wasted_percentage=10
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1
opcache.revalidate_path=1
opcache.enable_cli=1
opcache.jit_buffer_size=256M
opcache.jit=1255
opcache.use_cwd=1
opcache.file_cache_consistency_checks=1
And the only difference between the wrong one:
opcache.revalidate_path=1
What do you think @mringler ?
Thank you
Hey, thank you for the report!
Quite interesting. I don't understand how revalidate_path=0
would lead to the errors you were seeing (my guess would have been column not found exceptions), but this might very well be the magic and wonder of opcache.
Kudos for figuring it out!
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: