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: 40) |
Table of Contents
1. Overview
Zend_Db_Document implements abstract interface to nosql storages.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
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.
- This component will provide adapters to NOSQL stores
- This component will provide get/set operation
- This component will provide update/save document operation
- This component will provide MapRecude query interface
- This component will provide Document object (similar to Zend_Db_Table_Row_Abstract)
- This component will provide transformation adapters to support Zend_Db_Table
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
Considering the naming, I'd suggest for ZF 2.0 to name this:
Zend\Database\NoSQL
while moving the orignal Zend\Db to
Zend\Database\SQL
since both are databases.
Apr 13, 2010
Rostislav Mikhajliw
[15:53] <Freeaqingme> it has been decidede long ago that zend_db will be used for rdbms's only
[15:54] <DASPRiD> Freeaqingme, really?
[15:54] <DASPRiD> i must have missed that
[15:55] <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?
[15:56] <Freeaqingme> it was based on the fact that zend_db is oriented on rdbms's only
[15:57] <Freeaqingme> and you can't make it abstract enough to take care of any possible db in the world
But I think , it will be better Zend_Db_Document or Zend_Storage as Namespace for document oriented storages
Apr 13, 2010
Rob Zienert
I agree with this notion... Zend\Database\NoSQL and Zend\Database\SQL... or perhaps Zend\Persistence\...
Apr 13, 2010
Rostislav Mikhajliw
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)
Apr 13, 2010
Ben Scholzen
No, it is called Document-oriented database:
http://en.wikipedia.org/wiki/Document-oriented_database
Apr 14, 2010
Rostislav Mikhajliw
My old code http://github.com/necromant2005/zrails/blob/master/library/Zrails/Db/Document/Adapter/Couchdb.php
witch I'd migrate to Zend_Storage (Zend_Db_Document)
May 11, 2010
Matthew Weier O'Phinney
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.
I would recommend, however, looking at the MongoDB PHP API (http://php.net/mongo) 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.
(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).