[TYPO3-dev] DBAL error on fe_groups,pages

[Martin Kutschker]

R. van Twisk schrieb:
> Martin Kutschker wrote:
>> R. van Twisk schrieb:
>>  
>>> However what is the guideline for typo3 core? Is it allowed to do 
>>> joins in favor of execution speed, or should it do two separate 
>>> queries in favor of DBAL 'compatibility' (but slower).
>>
>> Of course you can replace all JOINs with loops and multiple queries, 
>> but why bother then with SQL? Sorry, it's IMNSHO ridiculous to ask for 
>> not using JOINs in any application that works with a SQL database.
>>   
> I totally agree with you martin and I was not asking for a replacement 
> for joins,

After posting I noticed that my use of the word "ridiculous" might be 
taken as offence. Please be assured that it was not meant that way.

> IMHO typo3 core should use much more of DB's possibilities like 
> references, stored procedure s etc....

The problem is that while we shouldn't care about the multi-DB featire 
of DBAL, we should care about DB portabilty. IMHO it's ok to support 
only a defines set of DB beside Mysql: PostgreSQL, Oracle and SQL 
Server. Unfortunately stored procedures are not portable. And as TYPO3 
is still supposed to run on Mysql 3.23 they are not even an option for 
Mysql. But I think we should raise the requirement at least to Mysql 4.0 
in TYPO3 4.2.

>>> I have been playing with the though to make a native PostgreSQL 
>>> driver for TYPO3 just like there is a native driver for MySQL. Any 
>>> thoughts on this?
>>
>> I played with the idea myself. If it were only about t3lib_db I had 
>> given it a try, but you need to XCLASS more files (for the installer 
>> etc). And I was not sure if I don't need ADOdb (like DBAL) in the end, 
>> so I never tried.
>>   
> I think it can be done without DBAL and being true native. I agree that 
> more files need to be xclassed to convert 'typo3 SQL' to PostgreSQL.
 > Possible for occasions  like get tables, get fields, alter table 
statements etc...

Exactly. Plus the code that reads Mysql CREATE TABLE statements and 
converts them into the syntax of other DBs.

>  From PostgreSQL 8.0 I think all functions can be implemented.
> 
> I am just waiting for a client that needs something like that since in 
> freetime I can't manage that.

I have only one customer who uses PostgreSQL and we use DBAL. Same 
situation for freetime for this issue on my part.

Masi