Bug #20470
closedColumn's default value is not properly quoted in CREATE TABLE
0%
Description
When creating a table a few steps are involved to parse the MySQL table creation definition and rewrite it to be compatible with another DBMS.
First step after parsing gives back an array [parsed_columns.png].
The value ['DEFAULT']['value']0 may contain a numeric value. The method compileFieldCfg() returns a definition as
I8 default '0' NOQUOTE
meaning this should be created as a integer with default value '0' (the single quote comes from ['DEFAULT']['value']1)
and it should be unquoted later on.
When having a string, if the default value is empty, then following definition is returned for instance:
C 255 default "''" NOQUOTE
You have to read it {double-quote}{single-quote}{single-quote}{double-quote}
The default value will get unquoted which result in '' (2x single quote) which is OK.
However when there is a default value which is non-numeric the following definition is returned:
C 255 default 'wwwhomepage' NOQUOTE
which is then unquoted and the actual code sent to the database is something like that:
CREATE TABLE "tx_euldap_server" (
...
"www" VARCHAR DEFAULT wwwhomepage,
...
)
which does not work as anybody may understand. For instance the SQL part of what is shown on [parsed_columns.png] is
CREATE TABLE "tx_euldap_server" (
...
"country" VARCHAR DEFAULT countrycode,
"www" VARCHAR DEFAULT wwwhomepage,
"user" VARCHAR DEFAULT '',
...
)
It is clear that the only valid definition is the last one with an empty default value. My patch removes the NOQUOTE
attribute when default value is not numeric and it results to a valid SQL:
CREATE TABLE "tx_euldap_server" (
...
"country" VARCHAR DEFAULT 'countrycode',
"www" VARCHAR DEFAULT 'wwwhomepage',
"user" VARCHAR DEFAULT '',
...
)
(issue imported from #M11142)
Files
Updated by Xavier Perseguers about 15 years ago
Could not reproduce for a while, lowering its severity.
Updated by Xavier Perseguers about 15 years ago
Added v2 against current trunk if this patch should ever be used (still pending)
Updated by Xavier Perseguers almost 15 years ago
I could confirm this behavior while writing unit tests for #12670
Updated by Xavier Perseguers almost 15 years ago
Committed to DBAL-trunk as revision 26752.
Backported to branch DBAL_1-0 as revision 26754.
Updated by Xavier Perseguers almost 15 years ago
Closed after testing (again) that EXT:eu_ldap could be installed properly