Skip to end of metadata
Go to start of metadata

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

Labels:
zend_config zend_config Delete
database database Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

6 Comments

comments.show.hide

  1. May 11, 2008

    Rob Allen

    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

    1. May 11, 2008

      Ben Scholzen

      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.

      1. Jun 10, 2008

        Rob Allen

        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.

        1. Jun 12, 2008

          Ben Scholzen

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

  2. Jun 24, 2008

    Alexander Veremyev

    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

  3. Nov 13, 2009

    Bulat Shakirzyanov

    Modeling the table after XML structure, we would have three different tables - xml_node, xml_node_element, xml_node_element_attribute, however these tables would have very similar columns (name, value, parent_id). So using the Single Table Inheritance Data Model, we could end up with one flat table as following:

    id - int (10) not null unsigned autoincrement
    name - varchar(255) not null
    parent_id - int(10) null unsigned default null
    value - varchar(255) null default null
    config_id - int(10) null unsigned default null
    extends - int(10) null unsigned default null

    unique (parent_id, name)

    Then something like

    <production>
    <db>
    <name>production_db</name>
    <password></password>
    <host>localhost</host>
    <user>root</user>
    </db>
    </production>
    <development extends="production">
    <db>
    <name>development_db</name>
    </db>
    </development>

    would be stored as

    id name parent_id value config_id extends
    1 production NULL NULL 1 NULL
    2 db 1 NULL 1 NULL
    3 name 2 production_db 1 NULL
    4 password 2   1 NULL
    5 user 2 root 1 NULL
    6 host 2 localhost 1 NULL
    7 development NULL NULL 2 1
    8 db 7 NULL 2 NULL
    9 name 8 developemnt_db 2 NULL