Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History


  • Create Zend\DB\Registry
    • Motivation: need a place for Driver connections, default and otherwise
    • Details: A registry would allow for named connections
      • Use case: read db and write db
      • Use case: marking a single connection as the default
  • Pluggable architecture
    • Motivation: there are plenty of feature requests that don't have a prope foundation for them to be implemented. Also, too many features that would currently require a BC break. Having a plugin system would reduce the likelyhood of feature requests that would require a BC break.
    • Details:
      • Ability to plug into Driver at various points
        • connection time
        • pre & post execute time
        • pre & post query time
      • Ability to plug into Query creation
        • plug into any SelectPart creation (see query abstraction for parts)
        • plug into pre & post assembly time
      • For a common "plugin" interface, this shall make use of Zend\SignalSlot
  • Distinct abstractions
    • Motivation: Currently, the Adapter classes contain both the connection abstraction (PHP Extension) function calls as well as some of the Vendor specific query abstraction. This makes the adapters too rigid and too large to improve over time.
    • Details:
      • Driver abstraction
        • Ability to specify if direct query or parameritized query should be default
        • PHP Extension specific: pdo_*, mysqli, oci, sqlsrv, etc
      • Query Abstraction
        • Insert, Update, Delete
        • Select: (column, from, where, group, having, order, limit, generic)
        • Vendor Specific Dialect: Mysql, Oracle, MSSQL, etc
  • Addition of DDL query abstraction
    • Motivation: DDL queries have been requested time and time again. In addition, our unit testing suite requires the creation of tables, columns and other schema specfic assets to test against.
    • Details:
      • (This component will be used to build proper environment for testing)
        • Create, Alter, Drop, etc
      • This will be part of the Query abstraction layer
  • Addition of a Metadata sub-component
    • Motivation: Currently, there is no formal way to encompass metadata in ZF. The adapter will provide describeTable() and Zend_Db_Table also does its own introspection over the schema. These types of lookups should be localized into a component that is capable of being both serialized and cached.
    • Details:
      • keep track of both introspected, and user provided schema information
      • these are cacheable objects
      • track relationships (FK constrains, Unique constraints)
      • track context of relationships (M2M, O2M, etc)
  • Separate Table & Row Gateway into sub-components of their own
    • Motivation: Currently, both the adapter and Zend_Db_Table have an interface for insert(), update(), and delete(). Since these are Table Gateway specfic concerns, that is the only place this type of interface should exist. Furthermore, Zend_Db_Table can be seen as a heavy component since, by default, it creates an object (Row Object) out of each row returned in the result set. For some use cases (like data warehousing), it would be beneficial to be able to use Zend_Db_Table object that returns array's of information for performances's sake.
    • Details:
      • Table Gateway
        • Optional coupling with Row Gateway
        • Give table gateway the default option to return array of data
        • Will take advantage of the metadata component
        • Will also have a plugin system: pre & post insert, update, delete time
      • Row Gateway
        • Similar in nature to the current implementation
        • Will take advantage of the metadata component
        • Will also have a plugin system: pre & post insert, update, delete time
  • Better testability in the Unit Tests:
    • Motivation: Currently, the existing unit tests are slow, and hard to work with.
    • Details:
      • Better separation of concerns
        • With a strong abstraction of driver and query, there is no need for dependent components to test each flavor of DB
        • Tests should utilize a standard schema for each test, unless something specific is needed which will be created and destroyed at the end of the unit test.
  • Base Plugins:
    • Type Converter:
      • Ability of a plugin to use metadata about a database, and user preferences to cast values from the database to desired primitive values and object types
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.