[TYPO3-mvc] Discussion: Storage Backend not compatible to DBAL

[Jigal van Hemert]

Hi,

First of all, please don't be offended by anything in this message; it's 
merely my opinion.

Xavier Perseguers wrote:
>> BUT: providing backends for all instead of using DBAL is not a 
>> solution to me.
> Neither to me.

DBAL is by the way it works not a very good solution to me. Trying to 
convert queries made for one database system to another will give 
problems one way or another.

This is clearly demonstrated by the wiki pages about how a developer 
should build queries to make them DBAL proof. The way 
t3lib_DB::listQuery() builds a list for checking fe_groups is very odd 
for someone who makes queries for recent versions of MySQL. The function 
FIND_IN_SET() [1] is a way simpler and more efficient way, but DBAL...

A more efficient way is indeed to supply a basic layer which provides 
database specific implementations of various routines.

The ideal way is that there are no database queries made at all anywhere 
in the code, except in the specific database layer.

>> Why?
>> 1. mixed envirenments would not be supported (as of DBAL)
>> 2. table Mappings would not be supported (mapping feature of extbase 
>> works only within one database)

Mixed environments would be a "cool feature", but I haven't heard of any 
company which wanted to store parts of the TYPO3 database in different 
DBMSs...

For what I've understood of FLOW3 the implementation of a content 
repository eliminates the use/need of database queries in packages. Part 
of the purpose of extbase is to provide developers with a platform on 
which they can build extensions which can be ported relatively easy to 
FLOW3 packages for use with TYPO3 version 5.

In this light a way to handle data with the least amount of SQL queries 
would be desirable and thus the way FLOW3 handles support for various 
DBMSs would also be the way to go (IMO).

[1] 
http://dev.mysql.com/doc/refman/5.1/en/string-functions.html#function_find-in-set

Regards, Jigal.