[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