<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_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.Zend Framework: Zend_Nosql_Mongo Component Proposal
Proposed Component Name
Zend_Nosql_Mongo
Developer Notes
http://framework.zend.com/wiki/display/ZFDEV/Zend_Nosql_Mongo
Proposers
Valentin Golev
Zend Liaison
TBD
Revision
1.0 - 6 January 2010: Initial Draft. (wiki revision: 10)
Table of Contents
1. Overview
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
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?
22 Comments
comments.show.hideJan 13, 2010
Coen Hyde
<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 />
Coen</p>
Jan 21, 2010
Valentin Golev
<p>Thanks!</p>
<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>
Jan 21, 2010
Magnier
<p>Hi,</p>
<p>some news of this very interesting proposal ?</p>
Jan 21, 2010
Valentin Golev
<p>We are waiting for Zend liason and for Coen's proposals <ac:emoticon ac:name="smile" /></p>
Jan 21, 2010
Kazusuke Sasezaki
<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="http://framework.zend.com/wiki/display/ZFPROP/Zend_Couch+-+Matthew+Weier+O%27Phinney?rootCommentId=9437581">http://framework.zend.com/wiki/display/ZFPROP/Zend_Couch+-+Matthew+Weier+O%27Phinney?rootCommentId=9437581</a></p>
Feb 08, 2010
John Wyles
<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>
Feb 23, 2010
Coen Hyde
<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>
Feb 23, 2010
John Wyles
<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="http://nosql-database.org/">http://nosql-database.org/</a></p>
Mar 03, 2010
Hector Virgen
<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 nosql-database.org uses, we could have the following namespaces:</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
Zend_DocDb
_Mongo
_Couch
_Riak
_Terrastore
_Thru
Zend_ColumnFamily
_Hadoop
_Cassandra
_Hypertable
]]></ac:plain-text-body></ac:macro>
<p>etc.</p>
Feb 23, 2010
Coen Hyde
<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>
Feb 23, 2010
Valentin Golev
<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 ( v.golev@gmail.com ), I'm glad to help you in my free time.</p>
Feb 23, 2010
John Wyles
<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>
Mar 03, 2010
Hector Virgen
<p>Anything we can do to keep this going? Is there a github repo or something we can download / contribute to?</p>
Mar 12, 2010
Coen Hyde
<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 />
Coen</p>
Mar 12, 2010
Fred Jiles
<p>Coen,</p>
<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>
Mar 12, 2010
Hector Virgen
<p>Sounds great, looking forward to testing it. Have you considered adding support for master/slave configurations?</p>
<p><a class="external-link" href="http://www.snailinaturtleneck.com/blog/2010/02/01/mongo-mailbag-masterslave-configuration/">http://www.snailinaturtleneck.com/blog/2010/02/01/mongo-mailbag-masterslave-configuration/</a></p>
Mar 24, 2010
Augusto Pascutti
<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>
Mar 29, 2010
Coen Hyde
<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="http://github.com/coen-hyde/Shanty-Mongo">http://github.com/coen-hyde/Shanty-Mongo</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>
Mar 30, 2010
Dennis Becker
<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]);
});
]]></ac:plain-text-body></ac:macro>
Mar 30, 2010
Coen Hyde
<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>
Mar 31, 2010
Dennis Becker
<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="http://www.snailinaturtleneck.com/blog/2010/02/01/mongo-mailbag-masterslave-configuration/">http://www.snailinaturtleneck.com/blog/2010/02/01/mongo-mailbag-masterslave-configuration/</a> - maybe this could help you.</p>
Mar 31, 2010
Coen Hyde
<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>