Skip to end of metadata
Go to start of metadata

<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_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: 10)

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_Object_Interface
  • 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.
  1. Jan 13, 2010

    <p>Hi Valentin,</p>

    <p>Good stuff! I am also writing a Zend framework compatible MongoDb adapter (about 50% complete). What i have done/will do is almost entirely as you layout above. There are a few things that i have implemented slightly differently that i would like to see in this adapter. Give me a couple of weeks and i'll get the code up for us to philosophise over;</p>

    <p>I would also like to see this MongoDb adapter named Zend_Mongo, rather than Zend_Nosql_Mongo. To me the nosql is rather superfluous, it increases the class names for no good reason.</p>

    <p>Cheers,<br />

    1. Jan 21, 2010


      <p>If you think about changing the proposal, feel free to introduce changes. If you think that proposal is not yet ready, I can move it from 'Ready for recommendation' category.</p>

      <p>I'd love to see your adapter, don't really want to write all the code from scratch again and again.</p>

  2. Jan 21, 2010


    <p>some news of this very interesting proposal ?</p>

    1. Jan 21, 2010

      <p>We are waiting for Zend liason and for Coen's proposals <ac:emoticon ac:name="smile" /></p>

  3. Jan 21, 2010

    <p>Nosql..? I think that "Zend_Nosql" is not good namespace.</p>

    <p>Had not namespace(Zend_DocDb) been considered for document-oriented database?<br />
    @see CouchDb's proposal page.
    <a class="external-link" href=""></a></p>

    1. Feb 08, 2010

      <p>I fully support this namespace (Zend_DocDB) and can see the emergence of other libraries that will utilize this as well. We already have a few (e.g. CouchDB, MongoDB, Riak, Terrastore, Persevere, etc.)</p>

      1. Feb 23, 2010

        <p>Maybe. The problem i see with having any kind of DocDb/NoSql namspace is that even though the databases you listed may be similar. They do not support a common feature set. Would such a namespace be an abstraction layer? In which case you would need to cater for the lowest common deominator. Or would it just be a grouping? In which case i see no real use as that will just increase the class name lenghts.</p>

        1. Feb 23, 2010

          <p>I think this mainly serves as a grouping; it really is just a namespace around a largely uncontested differentiation among the non-RDBMS persistence stores as is commonly known. One oft used and readily available resource to see this break down is here:</p>

          <p><a class="external-link" href=""></a></p>

          1. Mar 03, 2010

            <p>I don't like the Nosql namespace. That's like having a Noview or Nocontroller namespace. I'd prefer DocDB like John Wyles recommended, even if there is no common functionality between the various document stores.</p>

            <p>If we used the grouping that uses, we could have the following namespaces:</p>

            <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[



  4. Feb 23, 2010

    <p>By the way my prototype mongodb adapter is coming along well. It's taken a little longer than i expected <ac:emoticon ac:name="smile" />. However it has become a completely different beast to what Valentin layed out above. Shortly i will have it available to discuss. Currently it does not support advanced queries, however i know Valentin is the author of mongodloid and figured i'd leave that to his area of expertise.</p>

    1. Feb 23, 2010

      <p>Sadly my company is not interested in PHP anymore, so I think you can change the proposal and make it yours. If you want to discuss your proposal with me just write me an e-mail ( ), I'm glad to help you in my free time.</p>

    2. Feb 23, 2010

      <p>Can both of you please stay in touch with me as I am keenly interested in opening up the source for my own proprietary efforts. Thanks!</p>

  5. Mar 03, 2010

    <p>Anything we can do to keep this going? Is there a github repo or something we can download / contribute to?</p>

    1. Mar 12, 2010

      <p>Hi Hector,</p>

      <p>I have completed a working prototype and it should be up on github within a week. I'm just preparing some docs and a bit of a tutorial so you can all play with it. </p>

      <p>No units tests as of yet as the whole thing is a bit of an experiment.</p>

      <p>Cheers,<br />

      1. Mar 12, 2010


        <p>If you need some one to test this out, or go through your docs and tutorial for you and offer some feedback let me know, I would be more than willing to help in anyway.</p>

      2. Mar 12, 2010

        <p>Sounds great, looking forward to testing it. Have you considered adding support for master/slave configurations?</p>

        <p><a class="external-link" href=""></a></p>

      3. Mar 24, 2010

        <p>No need of docs for now I think ...<br />
        There is no need to polish things too much for now, just the base idea of the implementation should do just fine ;] </p>

  6. Mar 29, 2010

    <p>Sorry for taking so long. I didn't actually spend all that time writing docs <ac:emoticon ac:name="smile" /> ... I found a bug that required a significant modification of the source.</p>

    <p>Anyway here it is
    <a class="external-link" href=""></a></p>

    <p>The docs are a bit lack luster but it should give you the idea.</p>

    <p>Since this adapter is completely different to the proposal above i'll sign Zend's contributor form and create a separate proposal.</p>

    <p>One problem with my proposal is it requires php5.3. But i figured the Zend Framework would eventually move to 5.3 or would allow 5.3 only components in the extras. It would be possible to modify the adapter to not use late static binding but it should be a last resort as it would significantly reduce the developer friendliness.</p>

    <p>Any testing or feedback would is more than welcome. Unit tests would be worshiped.</p>

    1. Mar 30, 2010

      <p>PHP 5.3 support only comes with Zend Framework 2.0 - which would be released at the end of 2010. Because of this, I cannot use it at the moment, because I have only PHP 5.2.x installed. But here are some thoughts from me:</p>

      <p>This component feels a bit bad when using it. Creating a connection is ok, but the "Mongo" PECL extension only supports a connection with many servers or you have to create an object for each server you want to use. So a "defaultConnection" looks obsolete to me. Better would be to add at first a master server, and provide a possibillity to add slaves. Also there should be a flag with prevents reading from master server.</p>

      <p>Also Validators and Filters should, from my point of view, separated and defined as Validators and Filters.</p>

      <p>This looks like JavaScript-style - PHP does not now "function()" - is it supported in PHP 5.3? I'm wondering about this.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      self::addRequirementCreator('/^GreaterThan([\d]+)$/', function($data) {
      return new Zend_Validate_GreaterThan($data[1]);

  7. Mar 30, 2010

    <p>Hi Dennis,</p>

    <p>Re Connections: Yeah i haven't put much thought into the connection aspect at all, completely open to suggestion from those who know better.</p>

    <p>Re Validators and Filters: I did originally have them separate but it was a bit ugly having the configuration options for properties spread across multiple arrays. Plus there are other requirements that are not validators or filters such as the 'AsReference' and planned 'AsPartial'. If it this is something that bothers people, maybe we can prefix the requirements, such as 'Filter:{$filterName}' and 'Validator:{$validatorName}'</p>

    <p>Yes closures are supported in 5.3. The reason i have used closures in this instance is to allow the developers to supply custom requirement creators.</p>

    1. Mar 31, 2010

      <p>From my point of view, the supported validators and filters would be enough at the moment for use under ZF 1.x - so this could be removed to be compatible with PHP 5.2.x and no one would miss it at start <ac:emoticon ac:name="wink" /></p>

      <p>Kristins Chodorow has shown an example for master and multi slave connections at <a class="external-link" href=""></a> - maybe this could help you.</p>

      1. Mar 31, 2010

        <p>Cheers, for the link. I'll implement a nice solution <ac:emoticon ac:name="smile" /></p>

        <p>If we removed the closures we still wouldn't have 5.2.x compatibility as collections and documents are the same thing. When the a model is referred to statically we are talking to the collection, when it's an instance we are talking to a document. Late static binding.</p>

        <p>If ZF 2 will be out at the end of 2010, that's probably not too bad anyway (it's already April). It will give us time to get this polished and stable.</p>