This repository has been archived by the owner on Feb 5, 2024. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
3 additions
and
149 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Original file line | Diff line number | Diff line change |
---|---|---|---|
@@ -1,151 +1,5 @@ | |||
# CouchDB ODM | # CouchDB ODM | ||
|
|
||
# Current Status: | Doctrine CouchDB is a mapper between PHP and CouchDB documents. It uses a metadata mapping | ||
|
pattern to map the documents to plain old php objects, no ActiveRecord pattern or base class | ||
* basic CRUD is implemented | of any kind is necessary. | ||
* metadata reading implemented | |||
* many2one and many2many with lazyloading mostly implemented | |||
* flexible ID generation implemented | |||
* plenty of TODO's noted through out the source code | |||
* please use the Doctrine Jira to log tickets: http://www.doctrine-project.org/jira/browse/CODM | |||
|
|||
# Hackaton Discussions: CouchDB + Doctrine | |||
|
|||
##Problem 1: Query API | |||
|
|||
* Views | |||
* including ability to define limit, sort direction, include docs | |||
* CouchDB-Lucene hidden transparently in the Background | |||
* Allows a dynamic query language to be implemented | |||
* Depending on the search backend (query language translator) | |||
|
|||
##Problem 2: Lazy Loading | |||
|
|||
How to implement object-graph traversal transparently? | |||
|
|||
* two views required, because bi-directional relationships? | |||
* `emit([doc.type, doc.field, doc._id], 0);` (triple) | |||
|
|||
We need some matadata to be stored in doctrine couchdb odm documents: "type", "relations" | |||
|
|||
## Problem 3: Joins | |||
|
|||
2 possibilities: embedded, with ids | |||
|
|||
"Foreign Keys": | |||
|
|||
* one-to-many: save one key-reference in each "many"-document | |||
* many-to-many: save ids in the owning-side document | |||
* one-to-one: maybe good use-case for embedded documents | |||
|
|||
## Problem 4: Embedded Documents Use-Case? | |||
|
|||
Value objects (Color example) | |||
|
|||
## Problem 5: Computed Values from View | |||
|
|||
* By default we dump everything that isnt mapped to a property into a "values" array | |||
* Optionally provide a way to map these values to a key so that we can provide an associative array | |||
|
|||
## Problem 6: `@DynamicFields` | |||
|
|||
Just have mapping type "array". | |||
|
|||
class Address | |||
{ | |||
/** @var array | |||
public $additional = array(); | |||
} | |||
|
|||
## Problem 7: "Eventual Migration" / Liberal Reads | |||
|
|||
MongoODM has solution for that | |||
http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/migrating-schemas/en#migrating-schemas | |||
|
|||
## Problem 8: Write/Flushing changes | |||
|
|||
* Conflict Management throws an Exception into the users face :) | |||
|
|||
## Problem 9: Attachments | |||
|
|||
Easily lazyloaded by resource handle or "transparent" proxy | |||
|
|||
## Problem 10: HTTP Client | |||
|
|||
* Should be interfaced | |||
* Different implementations: Socket, Stream Wrapper, pecl/http | |||
|
|||
## Problem 11: Objects without "Doctrine Metadata" | |||
|
|||
* Eventual migration possibilities for this case should be possible | |||
|
|||
## Problem 12: ID Generation | |||
|
|||
* Assigned IDs (Username for the User) | |||
* Unique Constraints | |||
* UUID (Generate IDs upfront possible) | |||
|
|||
# Requirements | |||
|
|||
1. type of the document in each couchdb "doc" | |||
2. Expose revision to the user!!! | |||
3. metadata field in each "doctrine handled" document | |||
|
|||
## Struct | |||
|
|||
{ | |||
"_id": "asbaklsjdfksjddf", | |||
"__doctrine": { | |||
"type": "foo", | |||
"relations" : { | |||
"bar": [ "id1", "id2" ], // M:N | |||
} | |||
}, | |||
"fieldA": "foobar" | |||
"embeddedA": [{...}, {...}] | |||
} | |||
|
|||
## Views for relation retrieval | |||
|
|||
Related objects (works for 1:1, 1:n, n:1 and n:m) | |||
|
|||
function (doc) | |||
{ | |||
if (doc.doctrine_metadata && | |||
doc.doctrine_metadata.relations) | |||
{ | |||
var relations = doc.doctrine_metadata.relations; | |||
for ( type in relations ) | |||
{ | |||
for ( var i = 0; i < relations[type].length; ++i ) | |||
{ | |||
emit([doc._id, type, relations[type][i]], {"_id": relations[type][i]} ); | |||
} | |||
} | |||
} | |||
} | |||
|
|||
Reverse relations objects (works for 1:1, 1:n, n:1 and n:m) | |||
|
|||
function (doc) | |||
{ | |||
if (doc.doctrine_metadata && | |||
doc.doctrine_metadata.relations) | |||
{ | |||
var relations = doc.doctrine_metadata.relations; | |||
for ( type in relations ) | |||
{ | |||
for ( var i = 0; i < relations[type].length; ++i ) | |||
{ | |||
emit([relations[type][i], type, doc._id], {"_id": relations[type][i]} ); | |||
} | |||
} | |||
} | |||
} | |||
|
|||
## Also Natural Key Support | |||
class User | |||
{ | |||
/** @Id @Field */ | |||
public $username; | |||
} |