[TYPO3-dev] Database compare and database modification inconsistencies

[Xavier Perseguers]

Hi,

> 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.

The reason for special handling of NOT NULL was related to special
handling in Oracle:

// never add NOT NULL if running on Oracle and we have an empty string
as default
case ($feature === 'NOTNULL' &&
$GLOBALS['TYPO3_DB']->runningADOdbDriver('oci8')):

> 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".

Every change will have to be properly tested of course but I'm not
against enhancing this. I must confess however that supporting ALTERing
tables to add DEFAULT or NULL/NOT NULL clauses when it was "forgotten"
on first hand is not my top priority task and will consume quite some
time to be properly tested on:

- MySQL
- MS SQL
- Oracle
- PostgreSQL

I say not top priority because of the high amount of time needed to
enhance that with a 99% chance being for free.

But maybe it can "easily" be fixed for MySQL with no chance to alter the
behaviour in other DBMS and this could be fine as well.

>> 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 ?

DBAL comes with unit tests which *must* be run whenever DB handling or
SQL parser is changed. In fact all unit tests for those parts of TYPO3
are shipped with DBAL.

Whenever something is changed in those parts, I usually start by writing
a dedicated unit test to get a "red light" before it gets fixed and thus
turns to green.

> 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.

DBAL2 is stuck ATM because the initial work I did (implemented most main
parts of the SQL parser) turned out to be much cleaner be unfortunately
much slower than current array-based implementation. And I did not have
more time to invest into optimizing the generic and extensible
object-based implementation.

Furthermore, new paradigms such as Extbase-based extensions already have
an SQL abstraction and just lack a dedicated DBAL handling, either by
generically writing the final SQL query according to the underlying DBMS
or by having some per-supported-DBMS dedicated implementation as there
is no need to "parse" the query anymore. This part is not available
either...

-- 
Xavier Perseguers
Release Manager TYPO3 4.6

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org