[TYPO3-dev] DBAL error on fe_groups,pages

[R. van Twisk]

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,
I was just wondering what typo3's core perspective for this was, that's all.
IMHO typo3 core should use much more of DB's possibilities like 
references, stored procedure s etc....
>   
>> It's cool that DBAL can 'export' tables to other databases, 
>>     
>
> IMHO this is a gimmick of DBAL. The only real world expamples I could 
> image til now is storing the data of an extension or perhaps tt_adress 
> (for direct mail) in a different DB.
>   
Agreed, I wrote actually rvt_adodb to let me access other databases. 
Since it's 9 out of 10
a special case anyways. The idea of DBAL is nice, however in practice 
the current concept
is not usable.
>   
>> For now I leave the tables into mysql and I unfortunately need to write 
>> 'DB check' functions to delete appropriate records when a row get's deletes.
>>     
>
> You could try and XCLASS DBAL itself and replicate the fe_users table 
> (ie duplicate all INSERT/UPDATE/DELETE statements). But how to get DBAL 
> to do the JOIN with the right copy when doing a JOIN?
>   
I am not planning that anymore... I will write my DB check functions 
which is easy. Checking
each SQL statement is also not a good thing.
>   
>> 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...
 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.

Masi,

thanks for your input on this. it's clear to me now that typo3's core 
favors speed over compatibility
which is good in this case.


Ries