<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_Db_Document implements abstract interface to nosql storages. Currently Zend haven't got any adapters to NOSQL storages, but a lot of real application is needed this. Cause NOSQL stoges is more flexible than SQL RDMS, and provide to build a most powerful and performance application.
Zend Framework: Zend_Db_Document Component Proposal
Proposed Component Name
Zend_Db_Document
Developer Notes
http://framework.zend.com/wiki/display/ZFDEV/Zend_Db_Document
Proposers
Rostislav Mykhajliw
Zend Liaison
http://github.com/necromant2005/zeus
Revision
1.2 - 31 December 2010: Beta. (wiki revision: 41)
Table of Contents
1. Overview
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
4. Dependencies on Other Framework Components
- Zend_Json
- Zend_Http_Client
- Zend_Protobuff
5. Theory of Operation
The primary goal of this component is provide abstract interface to NoSQL storages, witch provide functional by get/set, search, map-reduce queries and very easy interface to update/save/validate document to storage. To do this, we must take several factors into account:
- Transform output result set to array
- Query languages are usually JavaScript, and How exactly build queries the most interesting is map-reduce queries. Cause for simple queries we can develop interface similar to Zend_Db_Select , witch current Adapter will transform into himself query language.
- It must provide full interface to direct queries
- In the first step adapter will provide simple interface get/set by key and direct interface for query.
- Version of documents (in general storages return system field _rev for revision and _id for UID of document)
- Integration with exist Zend\Db\Table
- Integration validation document structure
6. Milestones / Tasks
The first implement most popular nosql storages MongoDB/CouchDB and later all exists.
- Milestone 1: [DONE] create abstract classes storages and document
- Milestone 2: [DONE] build base functionality get/set by key
- Milestone 3: [DONE] integrate query builder
- Milestone 4: integrate query builder for map reduce
- Milestone 5: do new adapters and go to Milestone 1
.
7. Class Index
- Zend\Db\Document (factory class)
- Zend\Db\Document\AbtractAdapter
- Zend\Db\Document\AbstractDocument
- Zend\Db\Document\AbstractCollection
- Zend\Db\Document\Adapter\Mongo
- Zend\Db\Document\Adapter\Couch
- Zend\Db\Document\Adapter\Riak
- Zend\Db\Document\Adapter\Voldemort
- Zend\Db\Document\Document\Mongo
- Zend\Db\Document\Document\Couch
- Zend\Db\Document\Document\Riak
- Zend\Db\Document\Document\Voldemort
- Zend\Db\Document\Collection\Mongo
- Zend\Db\Document\Collection\Couch
- Zend\Db\Document\Collection\Riak
- Zend\Db\Document\Collection\Voldemort
8. Use Cases
| UC-01 |
|---|
Factory
| UC-02 |
|---|
Use adapter for get object and store
| UC-07 |
|---|
Create new document with document id
| UC-08 |
|---|
Create new document with auto generated document id
9. Class Skeletons
Exceptions
Zend\Db\Document\AbstractAdapter
Zend\Db\Document\AsbtractDocument
Zend\Db\Document\AbstractCollection
7 Comments
comments.show.hideApr 13, 2010
Ben Scholzen
<p>Considering the naming, I'd suggest for ZF 2.0 to name this:</p>
<p>Zend\Database\NoSQL</p>
<p>while moving the orignal Zend\Db to</p>
<p>Zend\Database\SQL</p>
<p>since both are databases.</p>
Apr 13, 2010
Rostislav Mikhajliw
<p><ac:link><ri:page ri:content-title="53" ri:space-key="15" /></ac:link> <Freeaqingme> it has been decidede long ago that zend_db will be used for rdbms's only<br />
<ac:link><ri:page ri:content-title="54" ri:space-key="15" /></ac:link> <DASPRiD> Freeaqingme, really?<br />
<ac:link><ri:page ri:content-title="54" ri:space-key="15" /></ac:link> <DASPRiD> i must have missed that<br />
<ac:link><ri:page ri:content-title="55" ri:space-key="15" /></ac:link> <DASPRiD> Freeaqingme, was that decision probably just based on the fact that it was not possible to split within the zend_db namespace due to bc breaks?<br />
<ac:link><ri:page ri:content-title="56" ri:space-key="15" /></ac:link> <Freeaqingme> it was based on the fact that zend_db is oriented on rdbms's only<br />
<ac:link><ri:page ri:content-title="57" ri:space-key="15" /></ac:link> <Freeaqingme> and you can't make it abstract enough to take care of any possible db in the world</p>
<p>But I think , it will be better Zend_Db_Document or Zend_Storage as Namespace for document oriented storages</p>
Apr 13, 2010
Rob Zienert
<p>I agree with this notion... Zend\Database\NoSQL and Zend\Database\SQL... or perhaps Zend\Persistence\...</p>
Apr 13, 2010
Rostislav Mikhajliw
<p>NoSQL is not databases , it's called 'document oriented storage' by right. That's why I propose to put it into namespace Zend\Storage or for maintaining compatibility Zend\Database\Document (or Zend\Database\Storage)</p>
Apr 13, 2010
Ben Scholzen
<p>No, it is called Document-oriented database:</p>
<p><a class="external-link" href="http://en.wikipedia.org/wiki/Document-oriented_database">http://en.wikipedia.org/wiki/Document-oriented_database</a></p>
Apr 14, 2010
Rostislav Mikhajliw
<p>My old code <a class="external-link" href="http://github.com/necromant2005/zrails/blob/master/library/Zrails/Db/Document/Adapter/Couchdb.php">http://github.com/necromant2005/zrails/blob/master/library/Zrails/Db/Document/Adapter/Couchdb.php</a><br />
witch I'd migrate to Zend_Storage (Zend_Db_Document)</p>
May 11, 2010
Matthew Weier O'Phinney
<p>Not all of the data storage listed are Document-oriented, nor do all of them use JSON for communication. The capabilities actually vary quite widely, which makes abstracting access a somewhat difficult task.</p>
<p>I <em>would</em> recommend, however, looking at the MongoDB PHP API (<a class="external-link" href="http://php.net/mongo">http://php.net/mongo</a>) as a model for abstraction. It does a good job of abstracting many common tasks, and I think the way that it models queries (as associative arrays, and using string comparison operators) could be quite useful. The handling of the result as a "Cursor" is very easy to model in PHP, as is the simplicity of selection of documents.</p>
<p>(That said, not all the NoSQL solutions listed here would be capable of using such queries, if any. As an example, CouchDB only supports ad-hoc querying via temporary views, which are not recommended for production, and views themselves are created via map/reduce functions, which are not a good fit for a query language).</p>