[TYPO3-mvc] Casting objects

[Jochen Rau]

Hi.

>> I have written an SQL parser (see
>> Tx_Extbase_Persistence_Storage_Typo3DbBackend). It translates the
>> generic Query Object Model into (hopefully) valid SQL. After that, It
>> invokes $GLOBALS['TYPO3_DB]->sql_query($sqlString).
>
> Funny, method sql_query() are deprecated in DBAL, XCLASS of t3lib_db.
> But the main method in t3lib_db is not deprecated.

Ooops.

>> Does that work for your use case?
>
> Unfortunately not as it only works for _DEFAULT handler in DBAL, which
> mean the handler that is used by TYPO3 itself, it does not work for
> other handlers. And the problem is that I use MySQL for TYPO3 itself and
> MSSQL to access data from a legacy database. Meaning I have two handlers
> and _DEFAULT is the MySQL one.
>
> Moreover, I know why sql_query is deprecated in DBAL, this is because
> the query is not processed at all, it is sent as this to the DBMS but in
> case of Oracle for instance (in another project that runs 100% on
> Oracle), I had to use mapping methods of DBAL which allow table and
> column names to be rewritten on the fly when communicating with the
> database, while TYPO3, or the ext that issued the query is not aware of
> this transformation. This is needed because there is a limit of 30
> characters for identifiers in Oracle, meaning standard tables from
> TemplaVoilà are not compatible with Oracle. When you use sql_query, the
> SQL parser is not used and the query cannot be rewritten to update field
> and table names...

Ok. I propose having an Abstract Storage Backend and extend this to have 
an MsqlBackend, OracleBackend, PdoBackend, WhatsoeverBackend. Do we then 
need DBAL anymore (I did not use it by now)?

The only thing is to reuse the existing database connection.

Regards
Jochen

-- 
Every nit picked is a bug fixed