[TYPO3-core] RFC: Blueprint database service

Thomas Maroschik tmaroschik at dfau.de
Wed Jun 4 17:24:22 CEST 2014


Hi Jigal,

Thanks for that blueprint. I really like concept and the approach of 
integrating Doctrine DBAL. Further I don't see the need to integrate ORM 
now, but we should not obstruct the possibility.

I propose a slightly different architecture that mitigates some of 
issues I discoverd in TYPO3 DBAL through the last years.

----------------------------------------------------------------------

class ConnectionPool (singleton)
   * contains all connections
   * not only a single global connection,
     because different connections may
     * have different transactional behavior
     * conflict with lastInsertId
       (eg hooks inserting stuff directly after the DB insert)
   * connections have an identifier
     * _DEFAULT is the identifier for default connection
       (similar to DBAL handlerKey)
   * a connection will be demanded with the class name of the class
     the connection is used in as identifier
     * eg $connectionPool->getConnectionForClass('DataHandler')
     * this way it will be possible to configure different connections
       for different classes
     * mocking of database connections in tests is easy then, can be
       registered temporarily in connection pool
     * if no specific connection is configured,
       default connection is taken
     * it will be easy to integrate DI this way in the future
   * creates them by Doctrine\DBAL\DriverManager on
     demand according to configuration

class {Plattform}Connection (maybe) extends Doctrine\DBAL\Connection
   * (maybe) because may not be necessary, eg for MySQL
   * has a dependency upon a query builder for it's platform
   * returns an instance of the suitable query builder
     $connection->createQueryBuilder(), sets itself as target
   * returns the schema manager for this plattform

class VirtualConnection extends Connection
   * just a facade for 1-n real connection
   * contains configuration of
     * mapping from tables to connections
     * column name mappings
   * returns an configured instance the VirtualQueryBuilder

class {Plattform}QueryBuilder extends Doctrine\DBAL\Query\QueryBuilder
   * has a reference to the connection it has been created by
   * to Doctrine DBAL the query builder is what to Extbase the query is
   * query then is executed similar by $queryBuilder->execute()
   * examples here [1]

class VirtualQueryBuilder extends Doctrine\DBAL\Query\QueryBuilder
   * takes care of the column mapping
   * takes care of not leaving the boundaries of a single connection

----------------------------------------------------------------------


Schema Comments
   * schema should be represented in form of migrations (up/down)
     that use the schema manager of DBAL
     * [2]
   * in schema plattform portable types provided by Doctrine DBAL
     should be used

Goals of the architecture
   * in order to be able to use more transactions in TYPO3 we need
     more connections simultaneously, thus a connection pool
   * singletons should be rarely and only used when really necessary
   * sane defaults, flexible configuration
   * assignment of individual connections to classes
     * use case: only a single class uses that other database and
       doesn't need the virtual connection
   * the layer on top Doctrine DBAL should be as light as possible
   * make our layer also usable for Doctrine ORM for the future

I'm looking forward for your comments :)

Greetz

Tom

[1] 
http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/query-builder.html
[2] 
http://doctrine-dbal.readthedocs.org/en/latest/reference/schema-representation.html
-- 
Thomas Maroschik
TYPO3 CMS Active Contributor

TYPO3 .... inspiring people to share!
Get involved: typo3.org


More information about the TYPO3-team-core mailing list