[TYPO3-dev] Database compare and database modification inconsistencies

[Adrien Crivelli]

Hi,

I agree with you, "reverting the patch" is a (strong) euphemism, but that
may be a starting point.

I'm not exactly familiar with the whole DBAL thing. And honestly parsing
SQL sounds quite a bad idea, but I guess we are stuck with that. At least
database structure is fairly more limited than SELECT queries.

Anyway I'll wait to see what Xavier has to say about that before making a
move...

Cheers,

Adrien


On 3 January 2012 17:58, Ernesto Baschny [cron IT] <ernst at cron-it.de> wrote:

> 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
>
>
>
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev
>