[TYPO3-dev] RFC - Remove DBAL in total

[ries van Twisk]

On Jan 29, 2009, at 6:25 AM, Karsten Dambekalns wrote:

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

Like I said, it was a proof of concept and some people knew about this  
but
didn't got to much response back, I think I made a post one day on  
typo3-dev even.



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

I don't know details anymore, but when I looked at the code of the  
install tool I did notice it
did create some 'funny' calls to TYPO3-DB layer (or not) and it was  
hard to make my system work
without modifying the install tool.

Actually the same problem happened with the EID system where the DB  
layer got initialized without
using a XCLASS method.

Two changes two core at the same time is to much for bug-track and if  
you don't have any fame
from the core them you will be out of luck.



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

I agree now.... TYPO3 V4 will have it's life on MySQL and I accept  
that now.

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

hehehehe In a perfect world :D

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

I understand your solution perfectly and why it was created like that  
and honestly,
I have done that once waaaaaay back on a phpnuke system (the SQL re- 
writer).

Lessen learned,  it's just that it slows down TYPO3 horribly and it  
would have been better
to create a better API so core and extensions could use this API to  
construct
SQL's for other databases rather then have some system analyze the  
SQL's and re-write them.

it was 'the' reason I create rvt_adodb, so I could use my PostgreSQL  
DB next to MySQL for my own extensions.


Anyways,
I think the discussion is as good as closed. There is hardly no  
interest to run TYPO3 on anything
else then MySQL (but not strict..... hehehehe ) and although I was  
hoping that there where more
people in need of PostgreSQ0L, MSSQL, Oracle or other databases I was  
totally wrong there. People tend
to like MySQL for one reason or a other I don't understand well.

As a personal note to Karsten, I do appreciate the work you have been  
doing and saved
my life a couple of times. And as you are a core dev for V5, I hope it  
will have better DB support other
then MYSQL.

Ries

>
>
>
> Regards,
> Karsten