[TYPO3-dev] RFC - Remove DBAL in total

[ries van Twisk]

On Jan 22, 2009, at 5:37 AM, Michael Greiner wrote:

> Hello,
>
> I've read all your posts on this issue and have a long and short  
> answer to this. For those who have just a minute, scroll down:
>
> First I agree with Mattes who wrote:
>
> "Don't get me wrong, I don't dislike DBAL in general, but I think it  
> is bad practice to ship an extension as part of the core that does not
>
> work. ... If DBAL is such a killer feature... why doesn't it work?"
>
> Dimitry comes also to the point to keep dbal but for a reason
> that didn't seem strong enough for some of us. He wrote:
>
> "It should be fixed, not removed. Lots of people use TYPO3 with  
> other databases. We keep DBAL."
>
> In my opinion the main argument for or against dbal in the core has  
> nothing to do with the number of people using it. I propose a more  
> sophisticated approach. As Typo3 is free software, let it also be  
> free no matter which system people want or have to use. To do so it  
> is absolutely crucial to come up with a stable DB abstraction.
>
> Ries wrote: "It does work properly..." - Ries, what do you mean? We  
> discussed it here how difficult it is, to get a whole system (with a  
> little more than only the core) run on something else than MySQL.
>
> Mattes is absolutely right when he says:
>
> "Again and again releases are shipped that simply do not work  
> because we have no QA that tests even PostgreSQL." - I'm completely  
> with you. This makes Typo3 a bad choice for any developer no matter  
> how good Typo3 is. Here we have to talk about reliability. Many  
> people don't dare to upgrade ANYTHING, because they know nothing  
> will work anymore for weeks and months. I hope you you can share  
> this experience.
>
> "Because core developers are not paid to implement features or fix  
> bugs. They fix whatever they want to fix... Free work means free  
> choice for the developers" says Dimitry but WHO tells the world WHAT  
> the developers want? It seems like they do not know themselves.
>
> Mathias sees the following options: "Either fix those conceptional  
> bugs, write a workaround or remove the extension from the core." And  
> he is sure:  "I don't tell the core devs how to do their job, I just  
> think that it harms TYPO3 if bugs labeled blocker or crash are not  
> fixed prior to a new release (even more if patches exist)." - which  
> I think is absolutely right.
>
>
> IN SHORT:
>
> In my opinion the main argument for or against dbal in the core has  
> nothing to do with the number of people using it.
>
> I propose a more sophisticated approach. As Typo3 is free software,
> let it also be free no matter which system people want or have
> to use. To do so it is absolutely crucial to come up with a stable
> DB abstraction.
>
> Two things do much harm to Typo3: New releases that are not working  
> because they are not fully tested and bad communication about what  
> the developers want. I don't want to tell any developer what he (or  
> she) should do, instead I want the developers to make clear to the  
> whole community what exactly they want. This includes a statement on  
> DB abstraction now and in future that is accepted by many  
> development teams, also the 5.0 team. This whole issue is far to  
> important to be solved just within a cluster.
>
>
> Michael

Well,

there are two things... 1) it does work.. we have it running so as  
other people do, I am not saying it's easy though.

2) It doesn't work easly out of the box, like so many other CMS  
systems you can pick the DB to run on.

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.

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.
I was waiting for the new install tool that would do a better job....

The problem with DB abstraction is not only within core, core runs  
fairly easy on any other DB however there are gazillions of extensions  
that uses typical MySQL code
that cannot function on other databases and that is not really the  
fault of TYPO3 core. However users will complain about that once they  
try on there favorite DB.


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

1) Make a better class set to abstract DB calls. This should include  
functions like how to to concate strings in a specific DB,  retreive  
schema information, others......
2) Make the install tool work with the new abstraction layer
3) Change core where needed to use this new abstraction layer
4) Inform extension developers to change there extensions to use the  
new functions within 1)

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

Personally I think we should get rid of these sql files within  
extensions at all and setup a SQL/XML schema for it, so you get away  
with these ugly
SQL files with native MySQL notation (Use InnoDB etc...) much like  
what AdoDB offers,
but I am afraid that that is out of the question right now and I think  
it's possible to use these SQL files and get rid of the MySQL  
specifics for other DB's
It just would make life easer for TYPO3 to update the DB with  
changes......


The above is quite a bit of work I am afraid, although not huge. it  
does solve the problem of running TYPO3 on a other RDBM other then  
MySQL.
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)
it does have some nice features to just get a couple of tables from a  
other db which we have been using and I know quite a bit of users do  
use it.

The above does allow to run TYPO3 more nativly on a other RDBM gaining  
it's full speed from that DB.

Ries