TYPO3 Core

A snippet from the core mailing list:

Indeed, those who rely on getting back a simple string from SELECTquery in a
DBAL-enabled environment may crash hard. In certain situations you get back
an array, containing a string and some field/value pairs for BLOB/CLOB
fields.

exec_SELECTquery takes care of doing the right things with that, but if you
simply put that into $GLOBALS['TYPO3_DB']->sql_query() it will fail (that is
what you would do with it, right?).

Now that of course is a shortcoming in the sql_query() method in the DBAL
extension.

So, the solution will be to make the sql_query() method able to handle the result of SELECTquery transparently, just as exec_SELECTquery() already does.

The same holds true for UPDATEquery(), by the way...

Oh, I just realized that this is complete nonsense. Of course SELECTquery() always returns a string, only INSERTquery() and UPDATEquery() don't always return a string.

This bug was raised after discussing why SELECTquery() and friends are deprecated. The reason is cited below, but a prerequisite is, that one still wants to use the DB API cleanyl and therefor will use sql_query() to execute the SQL retrieved from the mentioned methods. Now, here we go:
-------
If you look at the source, you'll notice that sql_query() only uses the _DEFAULT handler, never anything else.

This means that one really should use the exec_*() methods, because as soon as someone configures more than one handler, using e.g. SELECTquery() and sql_query() on a table configured for the other handler will break.

Reopened because the reason for closing was wrong.

There are 3 pairs of methods (INSERTquery/exec_INSERTquery etc) and a standalone method (sql_query). It's perfectly valid to use INSERTquery to generate (and log) a query and to execute it later on.

Sorry, if DBAL cannot hande this it's either a lame API or a too powerful all-dancing API (the handler concept).

There is one more drawback to not using the exec_* methods: Mapping is not done. I'll think about moving this around, but I am afraid it's not worth the hassle.

But the mapping is done for sql_query(), right? So anyone who is willing to cope with the performance penatly can use it for his own queries.

It's a pity that the query building facilites are so limited. If we had real great code for that noone ever would need to fiddle with his own queries any more. Anyway, you may deprecate whatever you want. It'll not be remove from 4.x and 5.0 isn't TYPO3 any more ;-)

Maybe in DBAL the behaviour can be changed so that INSERTquery() and UPDATEquery() always return an array or maybe even an object. So sql_query() knows if the statements comes from the generator functions or are genuine user supplied. In the former case it should do the same thing as the exec_* counterparts (simply executing the stuff) in the latter it should go on and parse the query.