Added by Ben Scholzen, last edited by Alexander Veremyev on Jun 24, 2008  (view change) show comment

Labels

 

Zend Framework: Zend_Config_Db Component Proposal

Proposed Component Name Zend_Config_Db
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Config_Db
Proposers Ben Scholzen
Alexander Veremyev (Zend Liaison)
Revision 1.0 - 10 May 2008: Initial proposal. (wiki revision: 5)

Table of Contents

1. Overview

Zend_Config_Db will allow reading and writing configs to databases supported by Zend_Db_Adapter. This may be useful for runtime stored values, like those which can be set by an administrator panel.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will only connect to the database if values are read or written.
  • This component will allow creating new values and groups at runtime.
  • This component will only query for required values and only catch all values if required by toArray().
  • This component will not support sections, as they are not a requirement for a dynamic config.
  • This component will not support merge (yet?).

4. Dependencies on Other Framework Components

  • Zend_Config

5. Theory of Operation

A Zend_Config_Db object is created with an instance of Zend_Db_Aadapter_Abstract. You may also specify another table name and the column names which are used. After instanciation it can be used like any other Zend_Config object

6. Milestones / Tasks

  • Milestone 1: [DONE] Proposal finished
  • Milestone 2: Waiting for community feedback
  • Milestone 3: Working prototype checked into http://zend.svn.dasprids.de
  • Milestone 4: Unit tests exist, work, and are checked into http://zend.svn.dasprids.de
  • Milestone 5: Proposal approval
  • Milestone 6: Initial documentation exists.

7. Class Index

  • Zend_Config_Db

8. Use Cases

UC-01

Creating a Zend_Config_Db instance

UC-02

Reading a value

UC-03

Writing a value to the database

9. Class Skeletons

Skeletons will follow later

Comments  (Hide Comments)

Some comments on the Requirements, Constraints, and Acceptance Criteria section:

  • If this component can create values and groups, then it is very different from the other Zend_Config component.
  • If this component doesn't support sections and inheritance then it is very different from the other Zend_Config components.
  • Not all servers are set up to allow the database user permission to create tables. Again, none of the other Zend_Config components create their own data stores.

Personally, I would suggest moving the creation of values, groups and tables into a sub-class that inherits from Zend_Config_Db.

Also, I suspect that you need a class skeleton before you can call the proposal finished

Posted by Rob Allen at May 11, 2008 02:20

So, then to make it more like the others, you would want the following stuff I guess:

  • A new interface, called Zend_Config_Writable_Interface
  • Support for sections and inheritance
  • Table structure and values/groups must be pre-inserted by the developer
  • Optionally, but not required at this time, the possibility to register plugins into the Zend_Config_Writable_Db, which allow creation of table structure and groups/values.

Am I right so far?

Well and about the the class skeleton: Usually they only show the public methods, and those won't / shouldn't differ from the other Zend_Config classes, exept the constructor for sure.

Posted by Ben Scholzen at May 11, 2008 08:05

I think that Zend_Config_DB must be able to support sections and inheritence for it to be considered part of Zend_Config.

I'm not sure what a new interface would do. I think Shahar's intended proposal for Zend_Config_Writer is where the ability for a config object to write persistent data should be concentrated.

Posted by Rob Allen at Jun 10, 2008 10:22

I don't think that an interface is required, since there come no new methods, which are not in the usual Zend_Config yet.

Posted by Ben Scholzen at Jun 12, 2008 05:35
Zend Comments

We have the following recomendations for the Zend_Config_Db proposal:

  • Proposal should indicate DB schema necessary for value storage.
  • Proposal should indicate what configuration options are available for configuring the object; does it expect just a table name? or the names of fields? or something else?
  • Proposal explicitly does not allow sections or inheritance (merge capability), which other config adapters utilize. This would make its usage inconsistent with the other adapters. This should be solved in one or another way.
  • It seems like it should re-use the Zend_Db_Table default adapter if no adapter is specified, or allow passing a table name to utilize.

Nevertheless, the idea of the proposal is very useful. So the proposal is moved to archived folder now, but is welcome to be extended and moved back to the review process

Posted by Alexander Veremyev at Jun 24, 2008 12:18