[TYPO3-dev] RFC - Remove DBAL in total

Karsten Dambekalns karsten at typo3.org
Thu Jan 29 12:25:32 CET 2009


Hi everyone.

A few comments on this thread using your mail to hook in. :)

On 22.01.2009 14:59 Uhr, ries van Twisk wrote:
> I created myself a more 'sophisticated' version as a proof of concept
> that I could run TYPO3 on PostgreSQL and SQLite3
> based on PDO extensions within PHP (I also created a version that runs
> through JDBC over quercus, but that's a other story...) but it works.

I heard quite a few times that people fixed a lot of issues and created 
this and that advanced version - but it seems the code always rots away 
in some dark corner instead of seeing the light of the community. Usual 
excuses include that it needs to be cleaned up, documented, checked, ...

> However I stopped working on this mainly because that the install tool
> was not using dbal at all and simply calls mysql directly to get schema
> information to make a 'diff' between between tables to propose the update.

Now that is strange. Admittedly I didn't cater for DBAL in the past (see 
above for some reasons, life runs in circles), but I am shocked to learn 
that. The install tool (not the 1-2-3 installer, the "real" one) used to 
use DBAL. Back in the old days one could use it to create tables in the 
target database configured for DBAL.

As with the fatal error about charsets, it seems the core is adjusted 
without anyone even thinking about DBAL. Sad, indeed.

> IMHO the following needs to be done for better DB abstraction:

Well, even back then we decided that this is probably not worth the hassle.

> Create a unit test somewhere down the line.....

No, wrong working order. Define the API by writing tests, the code. 
Honestly. Anyway, we all learned our lessons. :)

> Also don't want to get rid of what Karsten wrote (the current DBAL)
> although it's a horrible solution to run TYPO3 completely on other RDBM
> (it's slow)

Well, it is possible to write a non-ADOdb driver that uses native, 
optimized calls to your favourite database. We focused on ADOdb because 
it was a solution readily available.


Regards,
Karsten




More information about the TYPO3-dev mailing list