[TYPO3-core] SELECTquery() vs exec_SELECTquery()

[Karsten Dambekalns]

Hi.

On Thursday 01 June 2006 14:12, Martin Kutschker wrote:
> Karsten Dambekalns schrieb:
> > 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*. I added an explanation to the source in the DBAL ext.
 ...
> I were not talking abut sql_query()! My question was why SELECTquery is
> deprecated? DBAL or not, exec_SELECTquery should - and does! - only call
> SELECTquery and perform a DB execute function.

Yes, I understood this (late, but I got it). That is why I write that 
sql_query() has issues, and since it is the only way to make use of the raw 
result of SELECTquery(), the latter should not be used, too.

> No need to urge everyone to exec_SELECTquery. It's IMHO even more stupid as
> some DBs have the idea of prepared statements, which is more in line with
> SELECTquery.

True, but practically you cannot use prepared statements at all, currently.

<note>
One thing to keep in mind is, the DBAL was created to fit the needs of the 
core, not as a general silver bullet for handling arbitrary complex queries. 
The whole DB access structure was there, bound to MySQL, and has been 
abstracted as much as needed and as far as possible without breaking old 
code.

We probably all agree that the current DBAL is not here to stay forever, 
instead the whole way of accessing data - maybe not only coming from a 
database - should be designed from scratch. But this is more a task for 
version 5...
</note>

> sql_query OTOH is a totally different beast. I agree it's more difficult to
> use, buit unless the DB-API has more power (read more supported SQL
> options: aliases, functions, etc) you'll end up using this function.

Aliases for tables and fields (using the AS keyword or not) fully work in 
current code, and I have a bunch of changes in the pipeline that greatly 
enhance (and/orr add) function support.

> Perhaps DBAL could be taught to try and figure out the correct handler for
> a query passed to sql_query.

There would be an easy variant, that is looking at the last handler that has 
beeing used (set in SELECTquery() for instance), but this will break if you 
first fetch some SQL, then do some other exec_*query(), and afterwards call 
sql_query(). If the handler is not the same this will lead to very strange 
errors.

Doing it the right way adds more overhead, as one would either have to change 
the way queries are passed around (to include the handler), or parse at least 
the tables in the query again, to define the matching handler...

Karsten
-- 
Karsten Dambekalns
TYPO3 Association - Active Member
http://association.typo3.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20060602/13b551a3/attachment.pgp