[TASK] Use prepared statements in generic persistence 26/27426/19
authorFelix Oertel <felix@oer.tel>
Tue, 4 Feb 2014 15:42:29 +0000 (16:42 +0100)
committerErnesto Baschny <ernst@cron-it.de>
Wed, 12 Mar 2014 13:08:46 +0000 (14:08 +0100)
commitab2dc4e597b227dc7991aee5ba5bd2e77489c7ec
treedfb2fbc2e58f636fe61ee92c57f34f35922d7b9b
parent2eaa891a112ce076b59b7050c88ba8c86657dfa2
[TASK] Use prepared statements in generic persistence

While Typo3DbBackend claims to be the glue between Extbase
and TYPO3, it hardly uses the TYPO3 DB API.

This patch enhances getObjectData- and getObjectCountByQuery
- the main methods used when dealing with domain models
through a repository - to use the TYPO3 DB API. In conjunction
this enables Extbase to use the preparedStatement introduced
in TYPO3 4.5.

Because prepared queries might not be desirable in all circum-
stances, they are disabled by default. They can be enable on
a per-query-basis via
  $query->getQuerySettings()->setUsePreparedStatement(TRUE);

Prepared statements will *only* be used for SELECT queries.

* consistent use of the TYPO3 DB API
  use exec_SELECTgetRows and exec_SELECTcountRows() even for
  non-prepared queries. This should help a lot along the way
  to support DBAL.

* preparedStatement in custom statements
  When using custom statements, it's now possible to use a pre-
  pared statement in $query->statement(), instead of a query-
  string. The prepared statement has to be initialized already
  though, because Extbase cannot take care of splitting your
  custom query string. The parameters are given as array in the
  second argument as usual.

* deprecated using parameters in non-prepared custom statement
  If a custom query string is used with $query->statement(),
  giving the parameters in the second argument is deprecated.

* get count working
  Counting - especially with limit and offset - has been broken
  for quite some time now. By refactoring the limit and offset
  parameters and adapting exec_SELECTcountRows() this should
  now work again.

The next step is to separate the query parsing from the backend
and introduce an intelligent query cache. This will work as a
drop-in-replacement. The @todo-annotations are intended to stay
there for the next patch.

Resolves: #55360
Releases: 6.2
Change-Id: I91a3fd69470df178a8a5465511e50766b50d7f52
Reviewed-on: https://review.typo3.org/27426
Reviewed-by: Steffen Ritter
Tested-by: Steffen Ritter
Reviewed-by: Marc Bastian Heinrichs
Reviewed-by: Ernesto Baschny
Tested-by: Ernesto Baschny
typo3/sysext/extbase/Classes/Persistence/Generic/Qom/Statement.php
typo3/sysext/extbase/Classes/Persistence/Generic/Storage/Typo3DbBackend.php
typo3/sysext/extbase/Classes/Persistence/Generic/Typo3QuerySettings.php