[TYPO3-dev] Database compare and database modification inconsistencies

Ernesto Baschny [cron IT] ernst at cron-it.de
Tue Jan 3 09:58:39 CET 2012


Hi,

Adrien Crivelli schrieb am 03.01.2012 08:37:

> This is something I already mentionned in Steffen's thread about the most
> annoying TYPO3 bug:
> 
> The database compare and database modification have inconsistencies which
> are quite confusing. It's quite easy to write an ext_tables.sql which will
> be applied on database, but actually never show as "up do date" in
> extension manager (so it seems it didn't apply). This is mostly because of
> limitation around "NOT NULL" and "DEFAULT" values.
> 
> I dug in core code and found out that at least some part of the problem
> is related to http://bugs.typo3.org/view.php?id=2777 and its patch (see
> http://git.typo3.org/TYPO3v4/Core.gita=commit;h=5dcd656b37de6f5847f067f852d7a201d20e64d9
> ).
> 
> I would love to see my SQL actually been applied as I wrote it, and not
> been silently modified on the fly (and thus create side-effect when showing
> current status in EM). So I suggest to roughly revert the
> previously mentioned patch and assert that the SQL executed is as close as
> possible as what is read from ext_tables.sql.

Reverting that old fix won't really be the cure of all diseases, I suspect.

It would be cool to have that all working, it also bothered me for
years. The whole SQL parsing needs some shape lifting.

The comparison for the "COMPARE" part of the install tool (and also in
the EM) is (basically) done between
t3lib_install::getFieldDefinitions_database and
t3lib_install::getFieldDefinitions_fileContent. The "diff" is generated
by t3lib_install::getDatabaseExtra.

The database part will fetch the current definitions from the TYPO3_DB,
which in turn might work through DBAL. So you have to keep in mind that
the changes need to be DBAL compatible and also consider DB systems
other than MySQL.

If you want to "dig into it", I suggest to do it in small steps and get
some input from the core team and especially Xavier Perseguers, as he's
our DBAL "wizard".

> I would be ready to work on that, as long as the core team agree on the
> concept. So is there any reason not to do that ? And how could I guarantee
> my change don't break everything (as it's quite a critical feature), is
> there any tests procedure for that feature ?

Fixing the issue is also relevant for current maintained releases, like
4.5. For newer releases, AFAIK Xavier started some time ago with the
"DBAL2" which seems to contain some more modern SQL parsing routines
[1]. Maybe Xavier could explain what's the status here, if it somehow
relates to this part of the core, and if any further work on it is worth
it, so that it might be someday included in a TYPO3v4 release.

Thanks for your help!

Cheers,
Ernesto

[1]
http://git.typo3.org/TYPO3v4/Extensions/dbal.git?a=shortlog;h=refs/heads/incubation_DBAL2






More information about the TYPO3-dev mailing list