Merge origin/master

.gitignore

@@ -0,0 +1 @@
+*.pyc

en/reference/introduction.rst

@@ -58,7 +58,7 @@ No abstract/base-class nor interface was implemented, yet you can save an object
             private $headline;
             /** @Field(type="string") */
             private $text;
-            /** @Field(type="datetime) */
+            /** @Field(type="datetime") */
             private $publishDate;
             
             // getter/setter here
@@ -112,7 +112,7 @@ Write-Behind
 
 You may ask yourself why ``persist`` and ``flush`` are two separate functions in the previous example. Doctrine persistence semantics apply a performance optimization technique by aggregating all the required changes and synchronizing them back to the database at once. In the case of CouchDB ODM this means that all changes on objects (managed by CouchDB) in memory of the current PHP request are synchronized to CouchDB in a single POST request using the HTTP Bulk Document API. Compared to making an update request per document this leads to a considerable increase in performance.
 
-This approach has a drawback though with regards to the transactional semantics of CouchDB. By default the bulk update is forced using the allOrNothing parameter of the HTTP BUlk Document API, which means that in case of different versioning numbers it will produce document conflicts that you have to resolve later. Doctrine CouchDB ODM offers an event to resolve any document conflict and it is planned to offer automatic resolution strategies such as "First-One Wins" or "Last-One Wins". If you don't enable forcing changes to the CouchDB you can end up with inconsistent state, for example if one update of a document is accepted and another one is rejected.
+This approach has a drawback though with regards to the transactional semantics of CouchDB. By default the bulk update is forced using the allOrNothing parameter of the HTTP Bulk Document API, which means that in case of different versioning numbers it will produce document conflicts that you have to resolve later. Doctrine CouchDB ODM offers an event to resolve any document conflict and it is planned to offer automatic resolution strategies such as "First-One Wins" or "Last-One Wins". If you don't enable forcing changes to the CouchDB you can end up with inconsistent state, for example if one update of a document is accepted and another one is rejected.
 
 We haven't actually figured out the best way of handling "object transactions" ourselfes, but are experimenting with it to find the best possible solution before releasing a stable Doctrine CouchDB version. Feedback in this area is highly appreciated.
 

en/reference/map-reduce-queries.rst

@@ -15,7 +15,7 @@ design document in the database:
 .. code-block:: php
 
     <?php
-    use Doctrine\ODM\CouchDB\View\FolderDesignDocument;
+    use Doctrine\CouchDB\View\FolderDesignDocument;
 
     $view = new FolderDesignDocument("path/to/app/couchdb");
     $designDocJson = $view->getData();
@@ -41,7 +41,7 @@ the username map.js might look like:
 .. code-block:: javascript
 
     function(doc) {
-        if (doc.doctrine_metadata.type == 'Doctrine.Tests.Models.CMS.CmsUser') {
+        if (doc.type == 'Doctrine.Tests.Models.CMS.CmsUser') {
             emit(doc.username, doc._id);
         }
     }
@@ -59,7 +59,7 @@ in the CouchDB ODM Configuration:
     $config = $dm->getConfiguration();
     $config->addDesignDocument(
         "myapp", 
-        "Doctrine\ODM\CouchDB\View\FolderDesignDocument",
+        "Doctrine\CouchDB\View\FolderDesignDocument",
         "path/to/app/couchdb"
     );
 
@@ -78,7 +78,7 @@ Both queries have a common base class with a simple API:
 
     <?php
 
-    namespace Doctrine\ODM\CouchDB\View;
+    namespace Doctrine\CouchDB\View;
 
     abstract class AbstractQuery
     {
@@ -114,9 +114,7 @@ The following query parameter related methods exist in both the native and odm-q
 .. code-block:: php
 
     <?php
-    namespace Doctrine\ODM\CouchDB\View;
-
-    use Doctrine\ODM\CouchDB\DocumentManager;
+    namespace Doctrine\CouchDB\View;
 
     class Query extends AbstractQuery
     {
@@ -249,8 +247,8 @@ An example execution of the username view given above looks like:
     $query = $dm->createQuery("myapp", "username");
     $result = $query->setStartKey("b")
           ->setEndKey("c")
-          ->limit(100)
-          ->skip(20)
+          ->setLimit(100)
+          ->setSkip(20)
           ->onlyDocs(true)
           ->execute();
 
@@ -275,8 +273,8 @@ The following snippet shows the difference:
     $query = $dm->createQuery("myapp", "username");
     $result = $query->setStartKey("b")
           ->setEndKey("c")
-          ->limit(100)
-          ->skip(20)
+          ->setLimit(100)
+          ->setSkip(20)
           ->onlyDocs(true)
           ->execute();
 

en/reference/working-with-objects.rst

@@ -461,7 +461,7 @@ methods on a repository as follows:
     // A single user by its nickname
     $user = $dm->getRepository('User')->findOneBy(array('nickname' => 'romanb'));
 
-.. notice::
+.. note::
 
     Querying by simple conditions only works for documents with indexed fields.