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
New Proposal Template
This page has been created from a template that uses "zones." To proceed:
  1. Edit the page
  2. Replace sample content within each zone-data tag with your own content
  3. Remove this notice
  4. Save the page
  5. When you are ready for community review, move this page to the Ready for Review section on the edit page.
No placeholders allowed!
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.

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

Zend Framework: Zend_Nosql_Mongo Component Proposal

Proposed Component Name Zend_Nosql_Mongo
Developer Notes
Proposers Valentin Golev
Zend Liaison TBD
Revision 1.0 - 6 January 2010: Initial Draft. (wiki revision: 4)

Table of Contents

1. Overview

Zend_Nosql_Mongo is a namespace containing wrappers and adapters for PHP Mongo classes, intended to make them more handy, simple and compatible with other ZF classes, such as Zend_Paginator.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will expose the entire MongoDB API
  • This component will expose even the API not supported by PHP driver if it is exposed by Mongo DB commands
  • This component will provide class for a Mongo Object.
    • In a mongo object will be only string, int, bool, double, null, array (of any of these types, recursively), Mongo Object, date, MongoID, binary, regexp and JS Code fields. See also Data Types in Mongo
    • Fields will be able to be accessed as a member variables, like $object->subObject->subObjField for { subObject : { subObjField : 17 } }.
  • This component will provide objects for individual documents as well as document collections
    • Document objects will allow arbitrary fields
    • Document objects will provide accessors for document IDs
    • Document objects will allow arbitrary fields
    • Document objects will be instances of a class which extends BSON Object
    • Document objects will allow atomic operations like increment
    • Document Collections will be iterable
    • Document Collections will be countable
    • Document Collections will allow adding and removing documents
    • Document Collections will allow retrieving documents by ID
    • Document Collections will allow prohibition of arbitrary fields
    • Document Collections will allow strong client-side typing of fields, like 'int' or 'int|array(int)|null'
    • Document Collections will allow validators for fields
  • This component will allow using GridFS for storing files
    • This component will be able to be used with Zend MVC
  • This component will provide a special object for Query
    • Query will be countable
    • Query will be iterable (by returning Cursor for iteration)
  • This component will provide a special object for Cursor, which is returned by executing Query
    • Cursor will be countable
    • Cursor will be iterable
  • This component will allow to set a specific class for documents in specific collections, as soon as it implements a special interface
    • Cursor and Collection will return instances of these specific classes instead of usual Document classes

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Validate
  • Zend_Paginator
  • Zend_Date
  • Zend_Controller (for using GridFS with MVC)

5. Theory of Operation

Users create a link to Database, providing connection and db information to the Zend_Nosql_Mongo_Db.
Then they can get a link to a specific collection (which will be created, if not exists).

Users can create a Zend_Nosql_Mongo_Object from any array, as soon as all its values (recursively) can be converted to Mongo types. They can save Zend_Nosql_Mongo_Object to any collection. Saving operation, as well as retrieving, returns an instance of Zend_Nosql_Mongo_Document, which has a specific _id and knows a name of its collection.

Users can query any collection. They can add more and more conditions to the query. When they are done, they can transform the query to a cursor and iterate or array-access it.

Users can set a specific class for a document of specific collection. It must implement Zend_Nosql_Mongo_Document_Interface or, even better, inherit from Zend_Nosql_Mongo_Document. In this case, all cursors from queries on this collection will return the specified class.

Users can make document schema more strict by providing validators, strong typing and disallowing arbitrary fields for any collection. Values of each typed field will be tested if it has one of specified types. If not, it will be converted to the first of the type in the list. If the conversion fails and 'null' is not allowed for the field, the exception is thrown instead of saving a document.

6. Milestones / Tasks

  • Milestone 1: Initial proposal and prototype
  • Milestone 2: All unit tests
  • Milestone 3: Working code, all unit tests passed
  • Milestone 4: Documentation

7. Class Index

  • Zend_Nosql_Mongo_Db
  • Zend_Nosql_Mongo_Collection
  • Zend_Nosql_Mongo_Document
  • Zend_Nosql_Mongo_Document_Interface
  • Zend_Nosql_Mongo_Object
  • Zend_Nosql_Mongo_Query
  • Zend_Nosql_Mongo_Cursor
  • Zend_Nosql_Mongo_Id
  • Zend_Nosql_Mongo_Date
  • Zend_Nosql_Mongo_Regexp
  • Zend_Nosql_Mongo_Code
  • Zend_Nosql_Mongo_Gridfs
  • Zend_Nosql_Mongo_Gridfs_File
  • Zend_Nosql_Mongo_Gridfs_Cursor
  • Zend_Nosql_Mongo_Gridfs_Mvc?

8. Use Cases

9. Class Skeletons


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