[TYPO3-english] cooluri bug

Markus Klein klein.t3 at mfc-linz.at
Sun Dec 18 19:07:02 CET 2011


Hi!

> -----Original Message-----
> 
> Hi,
> 
> On 18-12-2011 6:40, Markus Klein wrote:
> >
> > closer look at the sql files now. It would be sufficient to move the
> > CREATE TABLE statements from ext_tables_static+adt.sql (which is the
> > only content) into ext_tables.sql and they would be accepted.
> > (Without any TCA definition)
> 
> 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?

> 
> > Trying to solve these issues requires some insignificant changes to
> > the field definitions. As image [2] illustrates, it is not possible to
> > get rid of all issues, as the default value reporting of mysql (SHOW
> > COLUMNS...) maps the default values ['', CURRENT_TIMESTAMP, NULL] to
> > NULL. So the Installer's COMPARE function cannot distinguish between
> > these default values and therefore compares them to default ''.
> 
> 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)
AFAIK the cache_* tables of TYPO3 are not in the TCA either, hence are not used via process_datamap().
The TCA is already huge, so keep it clear of stuff which is not necessary to be there. The link_* tables of cooluri are not necessary there.

I agree the current timestamp could be simply added to queries, which should make things compatible again.

> 
> 
> Sorry, my words were a bit clumsy. TYPO3 doesn't support the presence of tables which are not defined in the core or in an extension.
> The Install Tool detects such a table and (rightfully) suggests to remove it.
Ok, so we are one the same line anyway then. ;-)
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. (Had such a thing with intermediate synchronization tables.)
That's why I was suggesting this setting to really exclude such tables from being touched.
But I accept your -2 and these are edge cases anyway.

> 
> TYPO3 uses a subset of MySQL functionality for tables, columns and queries to be able to support a range of DBMSs. If an extension
> author takes the trouble (which is rather simple) to follow these rules the extension can also work on Oracle, PostgreSQL, MSSQL and
> contribute to
> TYPO3 being an Enterprise level system...
+1

> 
> --
> Kind regards / met vriendelijke groet,
> 
> Jigal van Hemert.

Kind regards
Markus



More information about the TYPO3-english mailing list