[TYPO3-english] cooluri bug

[Jigal van Hemert]

Hi,

On 18-12-2011 19:07, Markus Klein wrote:
>> -----Original Message----- ext_tables.sql should contain the table
>> definitions and ext_tables_static+adt.sql can contain statements
>> that will be executed when the extension is installed (static data,
>> etc.).
>
> I know that, what is your point in conjunction with cooluri?

See [1]. Cooluri has table definitions in ext_tables_static+adt.sql

>> That is because the those current_timestamp constructions are not
>> DBAL compatible. AFAIK it's MySQL specific and thus not supported
>> by the Install Tool. crdate/tstamp values are handled by
>> application logic and not by the database in TYPO3. If you use
>> t3lib_TCEmain::process_datamap() to handle records tstamp fields
>> are updated, crdate fields are filled, etc. If crdatetime was
>> called crdate (an integer) and the logic handled by the code, it
>> would be completely compatible.
>
> Sorry, but I've to correct your statement. The reason why the
> Installer "doesn't" support this has nothing to do with DBAL. The
> Installer is simply not able to tell, which default value is
> currently in effect on a certain field, due to MySQL. (Have a look
> here http://bugs.mysql.com/bug.php?id=3418)

This bug report is about the RAND() function ??

For a test I added the link_cache to my database. SHOW COLUMNS FORM 
link_cache; (the command used to retrieve column info shows:

Field      Type                 Null Key  Default               Extra
id         int(10) unsigned     NO   PRI  NULL                auto_increment
params     blob                 YES  MUL  NULL	
url        char(255)            YES  MUL  NULL	
tstamp     timestamp            NO        CURRENT_TIMESTAMP	on update 
CURRENT_TIMESTAMP
crdatetime datetime             YES   	NULL
sticky     tinyint(1) unsigned	YES   	0

It's just that t3lib_install_Sql::assembleFieldDefinition() doesn't 
support these (MySQL specific ?) constructions like default 
current_timestamp.

> Still there might be edge cases where you have to maintain additional
> tables in the same DB (completely unrelated to TYPO3), which should
> not be deleted.

The TYPO3 database should IMO not be used for data of other 
applications. If you need to access such data in TYPO3 you can always 
use DBAL to connect to a second database and even map the tables and 
columns to names which are understood by TYPO3 (you can even use 
TypoScript to read data from these mapped tables).

[1]
http://typo3.org/extensions/repository/view/cooluri/current/info/ext_tables_static%252Badt.sql/

-- 
Kind regards / met vriendelijke groet,

Jigal van Hemert.