cannot use data mapper with property named "status"
F3 v3.8.1 PHP v8.2
trying to set the property like this :
/* $object is a SQLMapper */
$object->status = "value";
var_dump($object);
output :
object(model\InstanceMdl)#10 (14) {
["table_name":protected]=>
string(8) "instance"
["db":protected]=>
object(DB\SQL)#8 (8) {
["uuid":protected]=>
string(13) "1og0nwux4fxex"
["pdo":protected]=>
object(PDO)#9 (0) {
}
["dsn":protected]=>
string(47) "pgsql:host=localhost;port=5432;dbname=dev.admin"
["engine":protected]=>
string(5) "pgsql"
["dbname":protected]=>
string(9) "dev.admin"
["trans":protected]=>
bool(false)
["rows":protected]=>
int(0)
["log":protected]=>
NULL
}
["engine":protected]=>
string(5) "pgsql"
["source":protected]=>
string(8) "instance"
["table":protected]=>
string(10) ""instance""
["as":protected]=>
NULL
["_id":protected]=>
NULL
["fields":protected]=>
array(9) {
...
["status"]=>
array(9) {
["type"]=>
string(12) "USER-DEFINED"
["pdo_type"]=>
int(2)
["default"]=>
NULL
["nullable"]=>
bool(false)
["pkey"]=>
bool(false)
["auto_inc"]=>
bool(false)
["value"]=>
NULL
["initial"]=>
NULL
["changed"]=>
bool(false)
}
}
["adhoc":protected]=>
array(0) {
}
["props":protected]=>
array(0) {
}
["query":protected]=>
array(0) {
}
["ptr":protected]=>
int(0)
["trigger":protected]=>
array(0) {
}
["status"]=>
string(9) "to_create"
}
it adds a anonymous property, but doesn't set the real db property correctly.
just renaming the DB field and set it with the new name works well. maybe this is a special keyword, that we shouldn't use ?
setting the value with this syntax works correctly :
$object->set("status", "value");
Yes, STATUS is a MySQL reserved key word: https://dev.mysql.com/doc/refman/8.0/en/keywords.html#keywords-8-0-detailed-S
Nonreserved keywords are permitted as identifiers without quoting. Reserved words are permitted as identifiers if you quote them as described in Section 9.2, “Schema Object Names”: https://dev.mysql.com/doc/refman/8.0/en/identifiers.html
yes, but we can use it with quotes, so the framework can do it ? it seems to have a special behavior on this case. BTW, in this case I'm using a postgresql database (in which "status" is not a reserved keyword)