Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="info"><ac:parameter ac:name="title">New Proposal Template</ac:parameter><ac:rich-text-body>
<p>This page has been created from a template that uses "zones." To proceed:</p>

<ol>
<li>Edit the page</li>
<li>Replace sample content within each zone-data tag with your own content</li>
<li>Remove this notice</li>
<li>Save the page</li>
<li>When you are ready for community review, move this page to the <ac:link><ri:page ri:content-title="Ready for Review" /></ac:link> section on the edit page.</li>
</ol>

<ac:macro ac:name="note"><ac:parameter ac:name="title">No placeholders allowed!</ac:parameter><ac:rich-text-body>
<p>Please do not create placeholders. Wait until you have sufficient content to replace all sample data in the proposal template before creating your proposal document.</p></ac:rich-text-body></ac:macro></ac:rich-text-body></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Db_Adapter_Alias Component Proposal

Proposed Component Name Zend_Db_Adapter_Alias
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Db_Adapter_Alias
Proposers Joe Lee
Zend Liaison TBD
Revision 0.1 - 20 October 2009: Incomplete WIP (wiki revision: 18)

Table of Contents

1. Overview

Zend_Db_Adapter_Alias is a simple component that allows multiple aliases for Zend_Db_Adapter. The main usage of this component is to minimise code repetition when writing Table Data Gateways that need to connect to multiple databases.

Why?

Currently, to write a Table Data Gateway that needs to connect to a non-default database adapter, we have to code this way:

A better way is to preset the Db Adapter in the Registry at Bootstrap first, which I think is still not efficient because of an instance of Zend_DB_Adapter is created and set into Registry at every page load, even when it is not used:

Zend_Db_Adapter_Alias is designed to:

  • Create the Database Adapter and set into Registry when it is required
  • Maintain a list of connection information in a Zend_Config file
  • Simplify writing Table Data Gateways that need to connect to multiple databases:
  • Allows Zend_Application to handle multiple database adapters through a new Resource plug-in, Zend_Application_Resource_DbAlias. See Issue Tracker ZF-7997

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

ToDo

Most requirements take the form of "foo will do ...." or "foo will not support ...", although different words and sentence structure might be used. Adding functionality to your proposal is requirements creep (bad), unless listed below. Discuss major changes with your team first, and then open a "feature improvement" issue against this component.

  • This component will correctly reads a developers mind for intent and generate the right configuration file.
  • The generated config file will not support XML, but will provide an extension point in the API.
  • This component will use no more memory than twice the size of all data it contains.
  • This component will include a factory method.
  • This component will not allow subclassing. (i.e. when reviewed, we expect to see "final" keyword in code)
  • This component will only generate data exports strictly complying with RFC 12345.
  • This component will validate input data against formats supported by ZF component Foo.
  • This component will not save any data using Zend_Cache or the filesystem. All transient data will be saved using Zend_Session.

4. Dependencies on Other Framework Components

  • Zend_Db
  • Zend_Db_Exception
  • Zend_Config

5. Theory of Operation

ToDo

The component is instantiated with a mind-link that ...

6. Milestones / Tasks

ToDo

Describe some intermediate state of this component in terms of design notes, additional material added to this page, and / code. Note any significant dependencies here, such as, "Milestone #3 can not be completed until feature Foo has been added to ZF component XYZ." Milestones will be required for acceptance of future proposals. They are not hard, and many times you will only need to think of the first three below.

  • Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

If a milestone is already done, begin the description with "[DONE]", like this:

  • Milestone #: [DONE] Unit tests ...

7. Class Index

  • Zend_Db_Adapter_Alias
  • Zend_Application_Resource_DbAlias
  • Zend_Db_Table_Abstract

8. Use Cases

UC-1 Setup using Bootstrap
database.ini
Bootstrap
UC-2 Setup using Zend_Application
application.ini
Writing Table Data Gateway

9. Class Skeletons

New Class Zend_Db_Adapter_Alias
Changes to Zend_Db_Table_Abstract
ToDo Zend_Application_Resource_DbAlias

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
proposal proposal Delete
zend_db zend_db Delete
database database Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Feb 05, 2011

    <p>Archiving this proposal, feel free to recover it when you want to work on it again. For more details see <a href="http://framework.zend.com/wiki/display/ZFDEV/Archiving+of+abandoned+proposals+(Feb+5+2011)">this email</a>.</p>