[TYPO3-english] static_info_tables data is not fully imported

[Boris Gulay]

18.02.2011 14:59, Xavier Perseguers пишет:
> Hi,
>
> Boris Gulay wrote:
>> I'm using TYPO3 4.4.6 with PostgreSQL 8.3.7.
>> After installing static_info_tables extension I can see only 29
>> languages instead of more than one hundred in source (of the plugin).
>> There is no errors in the web interface and in PHP error log.
>>
>> What goes wrong? How can I diagnose this problem?
>
> IIRC I found once that the 30th record to be inserted (in your case)
> contained some single quote that was not optimally escaped and that
> bugged TYPO3 with DBAL activated. Check your static records and fix the
> 30th record accordingly.
Sorry, I did not understand what do you mean. 30th record for 
static_languages is "English" and it looks OK.

I have made some investigations and found the problem.
SQL script to create static tables is contained in the extension twice: 
first time in ext_tables.sql and second in ext_tables_static+adt.sql. 
And (surprise!) order of columns in this two scripts is different! The 
second surprise is in the way records are inserted into this tables: 
there in no field names in INSERT statements.

What actually happens? First, SQL scripts from ext_tables.sql are 
executed and static_* tables are created. Then ext_tables_static+adt.sql 
is parsed and CREATE TABLE scripts for the same tables are executed, but 
DROP TABLE scripts are ignored. So, all the creations fails because 
tables already exists.

typo3 at typo3-ERROR:  relation "static_languages" already exists
typo3 at typo3-STATEMENT:  CREATE TABLE "static_languages" (
     "uid"                    INT8 NOT NULL,
     "pid"                    INT8 DEFAULT 0,
     "lg_iso_2"               VARCHAR(2) DEFAULT '',
     "lg_name_en"             VARCHAR(50) DEFAULT '',
     "lg_typo3"               VARCHAR(2) DEFAULT '',
     "lg_country_iso_2"       VARCHAR(2) DEFAULT '',
     "lg_collate_locale"      VARCHAR(5) DEFAULT '',
     "lg_name_local"          VARCHAR(99) DEFAULT '',
     "lg_sacred"              INT8 DEFAULT 0,
     "lg_constructed"         INT8 DEFAULT 0,
                      PRIMARY KEY ("uid")
     )WITHOUT OIDS

After each (failed) CREATE statement INSERT statement are executed. But 
they does not specify field name explicitly and order of values is for 
ext_tables_static not for ext_tables.sql! As you can imagine most of 
INSERT statements fails with similar errors.

typo3 at typo3-STATEMENT:  INSERT INTO "static_languages"
                     (
                         "uid",
                         "pid",
                         "lg_iso_2",
                         "lg_name_local",
                         "lg_name_en",
                         "lg_typo3",
                         "lg_country_iso_2",
                         "lg_collate_locale",
                         "lg_sacred",
                         "lg_constructed"
                     ) VALUES (
                         '2',
                         '0',
                         'AA',
                         'Afar',
                         '',
                         '',
                         '',
                         'Afaraf',
                         '0',
                         '0'
                     )
typo3 at typo3-ERROR:  value too long for type character varying(5)

For me I have solved this problem by adding field names to INSERT 
statement. But I'm sure that scripts in this extension must be fixed to 
be able to work correctly with DBAL and any supported databases. Before 
writing a message to author of this extension I want to ask you (as 
maintainer of DBAL extension) some questions.

* Is it OK to have CREATE scripts for the same (static) tables in two 
files in the extension? It seems to me that this scripts should be only 
in ext_tables_static. In ext_tables should be only one script for 
tx_staticinfotables_hotlist table. Is it correct?
* Why DROP TABLE scripts from ext_tables_static are not executed during 
extension installation process? I can see this statement in 
class.em_index.php:5403 but it does not actually executed.