If I load a document and it has an internal reference to the same document with the same ID, only responds to changes in the proxy document. The main document will not be considered and any change has no effect.

This is the error I get:

get_class() expects parameter 1 to be object, array given.

Stack Trace:

#0 [internal function]: {closure}(2, 'get_class() exp...', '/Library/WebSer...', 562, Array)
#1 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php(562): get_class(Array)
#2 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php(545): Doctrine\ODM\MongoDB\Persisters\BasicDocumentPersister->prepareReferencedDocValue(Array, Array)
#3 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php(536): Doctrine\ODM\MongoDB\Persisters\BasicDocumentPersister->prepareValue(Array, Array)
#4 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php(463): Doctrine\ODM\MongoDB\Persisters\BasicDocumentPersister->prepareValue(Array, Array)
#5 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php(209): Doctrine\ODM\MongoDB\Persisters\BasicDocumentPersister->prepareUpdateData(Object(App_Model_Ticket))
#6 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/UnitOfWork.php(771): Doctrine\ODM\MongoDB\Persisters\BasicDocumentPersister->update(Object(App_Model_Ticket), Array)
#7 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/UnitOfWork.php(281): Doctrine\ODM\MongoDB\UnitOfWork->executeUpdates(Object(Doctrine\ODM\MongoDB\Mapping\ClassMetadata), Array)
#8 /Library/WebServer/Documents/ktapi/library/Doctrine/ODM/MongoDB/DocumentManager.php(503): Doctrine\ODM\MongoDB\UnitOfWork->commit(Array)
#9 /Library/WebServer/Documents/ktmodels/library/App/Model/Service/Dao/Doctrine.php(26): Doctrine\ODM\MongoDB\DocumentManager->flush()
#10 /Library/WebServer/Documents/ktmodels/library/App/Model/Service/Abstract.php(54): App_Model_Service_Dao_Doctrine->save(Object(App_Model_Ticket))
#11 /Library/WebServer/Documents/ktmodels/library/App/Model/Abstract.php(215): App_Model_Service_Abstract->save(Object(App_Model_Ticket))
#12 /Library/WebServer/Documents/ktmodels/library/App/Model/Ticket.php(84): App_Model_Abstract->save()
#13 /Library/WebServer/Documents/ktapi/application/controllers/TicketController.php(145): App_Model_Ticket->save()
#14 /Library/WebServer/Documents/ktapi/library/Zend/Controller/Action.php(513): TicketController->putAction()
#15 /Library/WebServer/Documents/ktapi/library/Zend/Controller/Dispatcher/Standard.php(295): Zend_Controller_Action->dispatch('putAction')
#16 /Library/WebServer/Documents/ktapi/library/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#17 /Library/WebServer/Documents/ktapi/library/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#18 /Library/WebServer/Documents/ktapi/library/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#19 /Library/WebServer/Documents/ktapi/public/index.php(34): Zend_Application->run()
#20 {main}

Please tell me how I can be more precise or of more help. Do you need my models for debugging? (I do not want to post them here).

There is still a problem with Single Collection Inheritance.

Please consider the following code :

 
/**
 * @Document(db="forum", collection="Items")
 * @InheritanceType("SINGLE_COLLECTION")
 * @DiscriminatorField(fieldName="type")
 * @DiscriminatorMap({0="Items", 1="Stuffs"})
*/
class Items
{
    /**
     *
     * @id
     */
    public $id;

    /**
     * @String
     */
    public $title;
}



/**
 * @Document(db="forum", collection="Items")
*/
class Stuffs extends Items
{
    
    /**
     *
     * @id
     */
    public $id;

    /**
     * @String
     */
    public $stuffname;

}

$a = new Stuffs();
$a->stuffname = 'TTT';
$dm->persist($a);
$dm->flush();

Resulting in the database with :

 
{
   "_id": ObjectId("4d5dd082b53251b84e000000"),
   "stuffname": "TTT",
   "type": 1 
}

Now if I do :

 
$result = $dm->find('Items', $a->id);

then $result is an instance of Stuffs

But if I try :

 
$result = $dm->find('Items', '4d5dd082b53251b84e000000'); 

then $result is an instance of Items

Note that '$a->id' is a string, the same string containing '4d5dd082b53251b84e000000', so :

 
$result = $dm->find('Items', $a->id); 
$result = $dm->find('Items', '4d5dd082b53251b84e000000'); 

are semantically equivalent. It seems however that hydration would ignore the DiscriminatorMap in the second example.

However If you do :

 
$result = $dm->find('Stuffs', '4d5dd082b53251b84e000000'); 

You'll get a Stuffs as a result.

Now I tried to find a workaround when you don't know the type of the returned object. My initial intention was to first fetch a document with :

 
$result = $dm->find('Items', '4d5dd082b53251b84e000000'); 

Then I'm testing a property in the objet to see if it's a Stuffs, if it is, I tried an new :

 
$result = $dm->find('Stuffs', '4d5dd082b53251b84e000000'); 

In order to fetch a Stuffs. But ... I still get a *Items"!

So basically, if you do :

 
$result = $dm->find('Stuffs', '4d5dd082b53251b84e000000'); 

You get a Stuffs. But if you do :

 
$dm->find('Items', '4d5dd082b53251b84e000000'); 
$result = $dm->find('Stuffs', '4d5dd082b53251b84e000000'); 

You get a Items!

i have found a bug in the Cursor class in mongodb-odm:

https://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/Cursor.php#L85 this musst call the current function in the parent class, otherwise mistakes happen when there is a grid fs collection.

Pretty simple to reproduce. Here is the code from our own application. All we wanted to do was to select a subset of fields from the Article document, and found that if we did that and then did anything to cause the DM to mark those documents as modified, when they get flushed to mongo it corrupts your data. For example, article has a property "published" which is set to 1, and after I run this code below, it will set the "published" property to "null" on all documents.

$class = 'Bundle\ArticleBundle\Document\Article';
$documents = $dm->createQuery($class)>select('_id','title','user')>execute();
foreach($documents as $document)

$dm->flush();
exit;

If you take an document that has a referenceMany and overwrite a PersistentCollection of data with an array, even of the same data, the data is appended to the collection instead of replacing it.

If I have a document which has a EmbeddedDocument and this other name used as the variable name. Thus, when saving but not used by the special reserved name of the variable name. But when read out of the special reserved name is used. so is my EmbeddedDocument always empty when the specific name are different. Furthermore, when I set no specific name for it is also EmbeddedDocument empty.

Example:

/**
 * @EmbeddedDocument
 */
class SocialNetworkUser {
	/**
	 * @Int(name="id")
	 * @var int
	 */
	protected $id;
	/**
	 * @String(name="fN")
	 * @var string
	 */
	protected $firstName;
	/**
	 * @String(name="lN")
	 * @var string
	 */
	protected $lastName;
}

/**
 * @Document(collection="users")
 */
class User {
	/**
	 * @Id
	 */
	protected $id;
	/**
	 * @EmbedOne(
	 * 	discriminatorField="php",
	 * 	discriminatorMap={
	 * 		"fbu"="Documents\SocialNetworkUser "
	 * 	},
	 * 	name="snu",
	 * 	cascade={"persist", "remove"}
	 * )
	 */
	protected $socialNetworkUser;
}

$user = $this->dm->findOne('Documents\User', array('snu.id' => $this->Facebook->getUser()));

print_r($user->getSocialNetworkUser()):

Documents\SocialNetworkUser  Object
(
    [id:protected] => // Commented
    [firstName:protected] => 
    [lastName:protected] => 
)

in Mongo:

Array
(
    [_id] => 4c7b4fc3ed1590814d050000
    [snu] => Array
        (
            [id] => // Commented
            [firstName] => Thomas
            [lastName] => Adam
            [php] => fbu
        )
)

Correct but should be:

Array
(
    [_id] => 4c7b4fc3ed1590814d050000
    [snu] => Array
        (
            [id] => // Commented
            [fN] => Thomas
            [lN] => Adam
            [php] => fbu
        )
)

Please correct me if i'm wrong but it looks like that current implementation of XmlDriver does not support the following feature:

"discriminatorMap" for "EmbedMany"

http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/embedded-mapping/en#mixing-document-types

<?php

class User
{
/**

• @EmbedMany(
• discriminatorMap= { * "download"="DownloadTask", * "build"="BuildTask" * }
• )
  */
  private $tasks = array();
  }

This feature is very important for our project and without it looks like that we have to move to Docblock annotations instead of XML format which could be rather painful and time consuming.

If you have the database structure as:
'Group' Collection has 'tables' (ReferenceMany targetDocument="Documents\Table") and 'chairs' (ReferenceMany targetDocument="Documents\Chair").
'Table' Collection has 'glasses' (EmbedMany targetDocument="Documents\Glass") and a name as (@String).
'Chair' Collection has a name as (@String) and tablenames as (@Hash).
'Glass' Collection has name as (@String).

First, I simply add a glass to table and add that table to group. And create a chair and add it to group also.
$dm = $this->doctrine->getDM();
$group = new Group();
$table = new Table();
$chair = new Chair();
$glass = new Glass();

$group->tables[] = $table;
$group->chairs[] = $chair;
$table->glasses[] = $glass;

$dm->persist($group);
$dm->flush();
*At this point the tablenames in 'Chair' collection is not entered.

Now I call a function, which adds a new chair;
function addChair()
{
$dm = $this->doctrine->getDM();
$chair = new Chair();
$group = $dm->createQuery('Documents\Group')
->where('name','group')
->getSingleResult();
foreach($group->tables as $table)

$group->chairs[] = $chair;
$dm->persist($chair);
$dm->flush();
}

and as mentioned I traverse on tables to get table names and add those name in a new 'Chair' Collection's tablenames (@Hash).

Now in Db I have:
a group with two chairs and a table (both Referenced).
two chairs (one with an array of "tablenames" and one doesn't have "tablenames"),
a table with "TWO" embedded glasses <<--this is very strange I never added another glass to table!!!!

Note: As I call "addChair()" one more time the glasses in table get multiplied by two!!!
Please fix this asap.
Thanks
Regards
Ahsan

Hello,

MongoDB proposes an operator $or

http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-%24or

Can you add this feature in Doctrine\ODM\MongoDB\Query

Thank you

Julien

Repeatable in the following use case, when the default pushPull strategy is used for an embedMany collection:

• Persist an object with a single embedded object in its embedMany collection. Flush/clear/refetch.
• Clear the collection and add a new embedded object. Flush/clear/refetch.
• The containing object's collection now has two copies of the replacement object from the previous step.

I investigated this as best I could, and traced the problem to BasicDocumentPersister::prepareUpdateData() and the data it receives from UnitOfWork's changeset.

The UoW changeset simply reports the old/new embedded collections as arrays of raw data. This makes BasicDocumentPersister unable to distinguish whether a $set or $pullAll/$pushAll is an appropriate course of action, since it cannot discern whether the embedded objects are actually different (by SPL object hash) or merely changed. Following the logic in prepareUpdateData(), we end up doing two things when processing the update for the collection field:

• Since old !== new, and we're a collection field type, generate pull/push commands based on the delete/insert diffs.
• Since we're embedded and new evalutes to true, recursively call prepareUpdateData() on ourself, which will then go on to generate set commands.

This chain of commands will then reach BasicDocumentPersister::update() later on and given the logic check within:

> if ((isset($update[$this->cmd . 'pushAll']) || isset($update[$this->cmd . 'pullAll'])) && isset($update[$this->cmd . 'set'])) ...

The $set command will be executed first, followed by $pullAll/$pushAll later. This $set actually changes the very data that $pullAll expects to remove, so $pullAll will do nothing but $pushAll will still insert a copy of our new data. The end result is that we now have two copies of our new data in the collection.

The discriminatorField and discriminatorMap options are ignored by both the YAML and XML drivers.

Example:
This mapping fails to store the discriminator in the type field and instead uses _doctrine_class_name as the discriminatorField the mapping also reverts to using class names.

 
<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mongo-mapping>
    <document name="Application\Test\Document\Group" collection="groups">
        <field name="id" fieldName="id" id="true" />
        <field name="name" fieldName="name" type="string" />
        <embed-many field="people" discriminator-field="type">
            <discriminator-map>
                <discriminator-mapping class="Admin" value="Admin" />
                <discriminator-mapping class="User" value="User" />
            </discriminator-map>
        </embed-many>
    </document>
</doctrine-mongo-mapping>

I think that this is also a problem for referenced documents as well, as the code for the two is nearly identical.

I refactored addEmbedMapping and addReferenceMapping to call the same function addDocumentMapping
Commit can be found here http://github.com/dordille/mongodb-odm/commit/41ce2ee126ff7f82610130704dbec451384bfdd3

The setup is a document that has an embedded document. If the embedded document is persisted with at least one field set to null, the changeset for the parent document will include the embedded document, even if no changes have been made.

The reason is that the "$orgValue" in UnitOfWork::computeChangeSet() won't contain the null field at all, while the "$actualValue" contains the field properly set to a null value.

Test coverage and fix to follow.

I use the MODM-83 fix, now i cant delete childrens with a other embedded document:

{
   "_id" : ObjectId("4caeea835634c915360a0000"),
   "categories" : {
     "0" : {
       "id" : ObjectId("4cbd55f55634c99177030000"),
       "name" : "neue Kategorie",
       "questions" : {
         "0" : {
           "id" : ObjectId("4cbd55f75634c99177040000"),
           "name" : "neue Frage",
           "relevance" : 0,
           "multi" : 0,
           "answertype" : 0,
           "other" : 0
        }
      }
    }
  },
   "description" : "pipapo!",
   "name" : "ich bin ein Katalog",
   "version" : 1
}

Now i add a new answer too the question:

"questions" : {
         "0" : {
           "answers" : {
             "0" : {
               "id" : ObjectId("4cbd56b95634c99b5b090000"),
               "name" : "neue Antwort"
            }
          },
           "answertype" : 0,
           "id" : ObjectId("4cbd55f75634c99177040000"),
           "multi" : 0,
           "name" : "neue Frage",
           "other" : 0,
           "relevance" : 0
        } 
}

When i delete now the new answer i have a empty array and i cant delete the question from the categorie.

"questions" : {
         "0" : {
           "answers" : [
            
          ],
           "answertype" : 0,
           "id" : ObjectId("4cbd55f75634c99177040000"),
           "multi" : 0,
           "name" : "neue Frage",
           "other" : 0,
           "relevance" : 0
        }
      }

Its a unkillable entry now.
Sorry for my bad english.

The commit on October 4th introduced a bug for me.
Exactly this line:

http://github.com/doctrine/mongodb-odm/commit/8bd3aef4055cfded62687d5ad0e762e3f12a473d#commitcomment-167197

Now I always get an error, because embeddedDocument is an array, and so get_class fails.

Order of keys in embedded bson hashes in mongodb matters, so you can't $pullAll an embedded document if the order of keys is different from the one in mongodb:

code
{
_id: ObjectId('123'),
addresses: [

,

,
]
}
/code

then query like:

code
db.collection.update({_id: ObjectId('123')}, {$pullAll: {addresses: [

]}})
/code

would fail, because the order of keys ('zipCode', 'street') is different from the one stored in mongo ('street', 'zipCode'). More can be found here http://jira.mongodb.org/browse/SERVER-1914

Therefore, we need to force the order on every insert and update for consistency.

It appears that the prePersist and postPersist lifecycle events are called twice when persisting and removing a document. Not sure yet if this happens because its an inherited class, will setup a test to try and show behavior.

When embedded documents are persisted and then some of them are removed in just the right way, the resulting update will issue a $pullAll for ALL of the embedded documents and then a $pushAll on whichever embedded documents weren't actually removed. Obviously, only a $pullAll on the removed items is necessary.

Additionally, while the $pullAll and the $pushAll seem like they should add up to the correct finish (though inefficient), the removed items appear to not be removed correctly. The $pullAll falls correctly into the if loop found here: http://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php#L230, but the end result of that $pullAll in this case is that some items are not removed.

A test case for this is here: http://github.com/weaverryan/mongodb-odm/commit/9968697a2c07e31ecfdd8d55ecbf9bf39183d01e. The first case, testModifyGroupsArrayDirectly() tests for this. The second case relates to MODM-79.

Thanks - I've found the issue particular strange to nail down and inconsistent. If you spot any issues in my test cases, let me know.

I have a document with several collections referencing documents in other collections.

Doctrine ODM seems to have issues with ArrayCollections and realizing that elements are being taken out. I call ArrayCollection->clear() on those collections but when calculating the changeset Doctrine does not realize that some were deleted.

My scenario is following: I have a REST API. On the API I use Doctrine ODM as data backend.

Now when I get a request to update an object, I get the passed ID of the object, and populate all the fields.

However with collections I call clear() on the collection and then re-add all passed elements. This might not be a very elegant solution, but I don't have to worry about added / changed / deleted items. I pretty much just set a new collection.

However, when persisting this document, Doctrine does not seem to notice that I cleared the collection. It just adds all the objects I added to the collection. Therefore I have a lot of duplicate items in my collection.

Hi,

i have 3 documents : a contact, a professional address and a personal address
A contact embed the 2 addresses

The Contact class inherits from an abstract class DomainAbstract
The 2 addresses classes inherits from an abstract class Address which inherits from DomainAbstract

• DomainAbstract <- Contact
• DomainAbstract <- Address <- PersonalAddress, ProfessionalAddress

DomainAbstract is defined as mappedSuperclass

Address is defined as mappedSuperclass

PersonalAddress, ProfessionalAddress are embeddedDocument

But the fields defined by address are not inherited by embedded PersonalAddress and ProfessionalAddress ( but the fields in domainAbstract are like expected)

I think, 2 levels of inheritance and embedded document is wrong...

thx for help

ps: yaml mapping

The abstract class :

abstract class Cgd\DomainObject\DomainObjectAbstract

#Cgd.DomainObject.DomainObjectAbstract.dcm.yml
Cgd\DomainObject\DomainObjectAbstract:
  type: mappedSuperclass
  fields:
    id:
      fieldName: id
      id: true
    createdAt:
      fieldName: createdAt
      type: date
    updatedAt:
      fieldName: updatedAt
      type: date
  lifecycleCallbacks:
    prePersist: [onPreInsert]
    preUpdate: [onPreUpdate]

Here the inherited class

class App\Entity\Contact\Contact extends Cgd\DomainObject\DomainObjectAbstract

#App.Entity.Contact.Contact.dcm.yml
App\Entity\Contact\Contact:
  collection: contacts
  type: document
  fields:
    email:
      fieldName: email
      type: string
    status:
      fieldName: status
      type: int

If i add the lifecycleCallbacks in the InheritedClass yaml config. Events are working

all documents inherits from an abstract class Cgd\DomainObject\DomainObjectAbstract

The document App\Entity\Contact\Contact has many App\Entity\Contact\Program

abstract class Cgd\DomainObject\DomainObjectAbstract

#Cgd.DomainObject.DomainObjectAbstract.dcm.yml
Cgd\DomainObject\DomainObjectAbstract:
  type: mappedSuperclass
  fields:
    id:
      fieldName: id
      id: true
    createdAt:
      fieldName: createdAt
      type: date
    updatedAt:
      fieldName: updatedAt
      type: date
  lifecycleCallbacks:
    prePersist: [onPreInsert]
    preUpdate: [onPreUpdate]

Here the inherited class

class App\Entity\Contact\Contact extends Cgd\DomainObject\DomainObjectAbstract

#App.Entity.Contact.Contact.dcm.yml
App\Entity\Contact\Contact:
  collection: contacts
  type: document
  fields:
    email:
      fieldName: email
      type: string
    status:
      fieldName: status
      type: int
  embedMany:
    programs:
      targetDocument: App\Entity\Contact\Program
      cascade: all

The embedded

class App\Entity\Contact\Program extends Cgd\DomainObject\DomainObjectAbstract

#App.Entity.Contact.Program.dcm.yml
App\Entity\Contact\Program:
  type: embeddedDocument
  fields:
    name:
      fieldName: name
      type: string

No field from abstract class are populated in embedded document

There are cases when collection must not contain duplicates. Mongo has "$addToSet" atomic command for such cases. It would be great to have a separate strategy for that command when persisting collections / embedMany / referenceMany.

As far as I understand, Doctrine already supports "set" and "pushPull" strategy, so adding "addToSet" strategy should be possible, right?

After adding new entry to referenced collection of existing document, ODM generates invalid update query.

Here is a test case:

/** @Document(db="tests", collection="tests") */
class a
{
    /** @Id */
    protected $id;

    /** @ReferenceMany(targetDocument="b", cascade="all") */
    protected $b;

    function __construct($b) {$this->b = new ArrayCollection($b);}

    function getB() {return $this->b;}
}

/** @Document(db="tests", collection="tests2") */
class b
{
    /** @Id */
    protected $id;

    /** @String */
    protected $tmp;

    function __construct($v) {$this->tmp = $v;}
}

$a = new a(array(new b('first')));
$dm->persist($a);
$dm->flush(); // flush causes notices
$dm->refresh($a);

$a->getB()->add(new b('second'));
$dm->persist($a);
$dm->flush();
$dm->refresh($a);

print_r($a->getB()->toArray());

Expecting following output:

Array
(
    [0] => b Object
        (
            [id:protected] => 4c7c9eea0f9d502005000000
            [tmp:protected] => first
        )

    [1] => b Object
        (
            [id:protected] => 4c7c9eea0f9d502005020000
            [tmp:protected] => second
        )

)

But getting:

Array
(
    [0] => b Object
        (
            [id:protected] => 4c7c9eea0f9d502005000000
            [tmp:protected] => first
        )

    [1] => b Object
        (
            [id:protected] => 4c7c9eea0f9d502005000000
            [tmp:protected] => first
        )

    [2] => b Object
        (
            [id:protected] => 4c7c9eea0f9d502005020000
            [tmp:protected] => second
        )

)

I suggest adding a new feature called @DynamicFields. The idea is from roman and documeneted here: http://github.com/romanb/couchdb-persistence-api/blob/master/src/main/java/org/code_factory/couch/annotations/DynamicFields.java

Idea: Save all "left-over" fields of the result in an array.

This would greatly enhance the flexibility of document mappers

Simple test case to reproduce:

/** @Document(db="tests", collection="tests") */
class a {
    /** @Id */
    protected $id;

    /** @Collection */
    protected $b = array('test');

    function setB($b) {$this->b = $b;}
}

$a = new a();
$dm->persist($a);
$dm->flush();
$dm->refresh($a);

$a->setB(new ArrayCollection(array('test')));
$dm->persist($a);
$dm->flush();

Getting PHP warning:

PHP Warning:  array_udiff_assoc(): Argument #2 is not an array in Doctrine\ODM\MongoDB\Persisters\BasicDocumentPersister.php on line 458

Getting following errors when trying to persist GridFS file.

Trying to get property of non-object in file Doctrine\ODM\MongoDB\MongoCollection.php on line 196 
Undefined index: _id in file Doctrine\ODM\MongoDB\Persisters\BasicDocumentPersister.php on line 163 

Unfortunately couldn't create reproducable test-case yet, but if that is not an obvious issue, please let me know, I'll try to dig deeper and get the test case.

GridFs file is stored incorrectly after two flushes.

Consider an example:

/** @Document(db="tests", collection="fs") */
class File
{
    /** @Id */
    protected $id;

    /** @File */
    protected $file;

    function  __construct($source) {$this->file = $source;}
}

$file = new File(__DIR__ . '/test.txt');

$dm->persist($file);
$dm->flush();
$dm->flush();

After second flush, doctrine will also store "file" property as if it was a regular object. Expecting:

{
  "_id": "4c777fc00f9d505407020000",
  "filename": "/test.txt",
  "uploadDate": {
    "sec": 1282899904,
    "usec": 0
  },
  "length": 10,
  "chunkSize": 262144,
  "md5": "76ce9f441de2ed5de337d391ad4516b7"
}

Actual result:

{
  "_id": "4c777f780f9d508416020000",
  "chunkSize": 262144,
  "file": {
    "file": {
      "_id": {},
      "filename": "/test.txt",
      "uploadDate": {
        "sec": 1282899832,
        "usec": 0
      },
      "length": 10,
      "chunkSize": 262144,
      "md5": "76ce9f441de2ed5de337d391ad4516b7"
    },
    "": {
      "w": 1,
      "wtimeout": 10000,
      "chunks": {
        "w": 1,
        "wtimeout": 10000
      },
      "": "fs.chunks"
    }
  },
  "filename": "/test.txt",
  "length": 10,
  "md5": "76ce9f441de2ed5de337d391ad4516b7",
  "uploadDate": {
    "sec": 1282899832,
    "usec": 0
  }
}

P.S. Unfortunately cannot use PHPUnit 3.5 right now to provide unit test.

Description of the problem here:

http://stackoverflow.com/questions/6103483/doctrine-mongodb-odm-load-referenced-documents

subj

it happens because the code goes out of the function at line 334 in file
\Doctrine\ODM\MongoDB\MongoCollection.php
without invoking appropriate event handlers

thanks!

Currently if document doesn't have "db" mapping, it is taken from defaultDb configuration and assigned to classmetadata (in ClassMetadataFactory).

But if we have two documentManagers with different defaultDb configuration, second manager's configuration will be ignored, because "db" value is already set in classMetadata (when the 1st manager was created).

It gets worse with metadata caching, as defaultDb setting is only taken in account when metadata is stored in cache.

This affects a common use-case, when each customer has his own database and defaultDb is defined at runtime.

I am not sure if it's a bug of the framework or a bug in implementation of array_slice function in PHP
but when I try to pass @ReferenceMany field value into array_slice built-in PHP function it fails with error:

==============================================
array_slice() expects parameter 1 to be array, object given
==============================================

I know that PersistentCollection has method "slice" (at least in master branch) but my concern is backward compatibility with the code which treats ReferenceMany type fields as arrays.
The old code works perfectly until it uses array_slice.

Please let me know are there any workarounds for this or probably you guys are going to implement some fix?

Thanks a lot!

On DocumentManager::merge() the following error happens:

Fatal error: Call to undefined method Doctrine\ODM\MongoDB\Mapping\ClassMetadata::setIdentifierValues() in /projects/tbi_doctrine/vendors/doctrine/odm/lib/Doctrine/ODM/MongoDB/UnitOfWork.php on line 1378

@Collection(strategy="set")
works fine

but
==========================================

@Field(type="collection", strategy="set")
causes error:
Fatal error: Uncaught exception 'BadMethodCallException' with message 'Unknown property 'strategy' on annotation 'Doctrine\ODM\MongoDB\Mapping\Field'.' in /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/Annotation.php on line 77

BadMethodCallException: Unknown property 'strategy' on annotation 'Doctrine\ODM\MongoDB\Mapping\Field'. in /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/Annotation.php on line 77

Call Stack:
0.0007 691072 1.

() /projects/tbi_doctrine/lab/doctrine/insert.php:0
0.0808 6313168 2. Doctrine\ODM\MongoDB\DocumentManager->persist() /projects/tbi_doctrine/lab/doctrine/insert.php:34
0.0809 6313168 3. Doctrine\ODM\MongoDB\UnitOfWork->persist() /projects/tbi_doctrine/vendors/doctrine/odm/lib/Doctrine/ODM/MongoDB/DocumentManager.php:338
0.0809 6313248 4. Doctrine\ODM\MongoDB\DocumentManager->getClassMetadata() /projects/tbi_doctrine/vendors/doctrine/odm/lib/Doctrine/ODM/MongoDB/UnitOfWork.php:1177
0.0809 6313248 5. Doctrine\ODM\MongoDB\Mapping\ClassMetadataFactory->getMetadataFor() /projects/tbi_doctrine/vendors/doctrine/odm/lib/Doctrine/ODM/MongoDB/DocumentManager.php:250
0.0809 6313248 6. Doctrine\ODM\MongoDB\Mapping\ClassMetadataFactory->loadMetadata() /projects/tbi_doctrine/vendors/doctrine/odm/lib/Doctrine/ODM/MongoDB/Mapping/ClassMetadataFactory.php:165
0.0957 6734784 7. Doctrine\ODM\MongoDB\Mapping\Driver\AnnotationDriver->loadMetadataForClass() /projects/tbi_doctrine/vendors/doctrine/odm/lib/Doctrine/ODM/MongoDB/Mapping/ClassMetadataFactory.php:221
0.0978 6669016 8. Doctrine\Common\Annotations\AnnotationReader->getPropertyAnnotation() /projects/tbi_doctrine/vendors/doctrine/odm/lib/Doctrine/ODM/MongoDB/Mapping/Driver/AnnotationDriver.php:182
0.0978 6669016 9. Doctrine\Common\Annotations\AnnotationReader->getPropertyAnnotations() /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/AnnotationReader.php:216
0.0979 6669392 10. Doctrine\Common\Annotations\Parser->parse() /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/AnnotationReader.php:201
0.0983 6678712 11. Doctrine\Common\Annotations\Parser->Annotations() /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/Parser.php:209
0.0983 6678928 12. Doctrine\Common\Annotations\Parser->Annotation() /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/Parser.php:270
0.0986 6680200 13. Doctrine\Common\Annotations\Parser->newAnnotation() /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/Parser.php:349
0.0986 6680840 14. Doctrine\Common\Annotations\Annotation->__construct() /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/Parser.php:536
0.0986 6681624 15. Doctrine\Common\Annotations\Annotation->__set() /projects/tbi_doctrine/vendors/doctrine/common/lib/Doctrine/Common/Annotations/Annotation.php:0

It would be really great if the method "load" is renamed to something more protected like "__load" or "_doctrineOdmLoad" like it has done for public properties
public $__dm;
public $__identifier;
public $_isInitialized_ = false;

Because otherwise if a referenced document has the same method "load" it causes error like this

"Fatal error: Cannot redeclare Proxies\ProjectProxy::load() in /projects/tbi_doctrine/tmp/doctrine/proxies/ProjectProxy.php on line 46"

It looks like that "name" attribute is not supported anymore in @Field annotation

http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/annotations-reference/en#ann_field
> name - By default the property name is used for the mongodb field name also, however the 'name' attribute allows you to specify the field name.

For instance the code below produces a document inside "mydocs" collection which has only one property "first_name" instead of two:

/** @Document(collection="mydocs") */
class MyDocument
{
/** @Id */
public $id;

/** @Field(type="string") */
public $first_name;

/** @Field(type="string", name="last_name") */
protected $_last_name;

public function __get($propertyName)
{
return $this->

= $propertyValue;
}
}

$doc = new MyDocument();
$doc->first_name = 'aaa';
$doc->last_name = 'bbb';
dm()->persist($doc);
dm()->flush();

I have two documents:

@Document
class A {
/** @Id */
public $id;
/** @ReferenceOne */
public $b;
}

@Document
class B {
/** @Id */
public $id;
}

I have an already persisted instance of B, which A references,
though while persisting A and examining the resulting collection the id of B is missing.

{
_id: '000123',
b: {
$db: 'mydb',
$id: '',
$ref: 'b'
}
}

I debugged the code and found the error occurs in DocumentPersister.php at line 210 in the latest git version as of this posting.
The code is:

$inserts[$oid] = $data;

where $data is:

array(
_id => MongoId(000123),
b => array(
$ref => 'b',
$id => MongoID(123000),
$db => 'mydb'
)
)

and $inserts[$oid] becomes:

array(
$oid = array(
_id => MongoId(000123),
b => array(
$ref => 'b',
$id => MongoID(),
$db => 'mydb'
)
)
)

This assignment makes the MongoID disappear somehow!!?

Can't figure it out, could this be a problem with PHP itself?

$options are not used for update queries

=> how can we do an update(

) ?

 
diff -rup doctrine-mongodb-odm-a0667bb/lib/vendor/doctrine-mongodb/lib/Doctrine/MongoDB/Query/Query.php mongodb_odm/lib/vendor/doctrine-mongodb/lib/Doctrine/MongoDB/Query/Query.php
--- doctrine-mongodb-odm-a0667bb/lib/vendor/doctrine-mongodb/lib/Doctrine/MongoDB/Query/Query.php	2011-01-17 06:38:18.000000000 +0100
+++ mongodb_odm/lib/vendor/doctrine-mongodb/lib/Doctrine/MongoDB/Query/Query.php	2011-01-31 17:34:04.000000000 +0100
@@ -172,7 +172,7 @@ class Query implements IteratorAggregate
                 return $this->collection->insert($this->query['newObj']);
 
             case self::TYPE_UPDATE:
-                return $this->collection->update($this->query['query'], $this->query['newObj']);
+                return $this->collection->update($this->query['query'], $this->query['newObj'], $this->options);
 
             case self::TYPE_REMOVE:
                 return $this->collection->remove($this->query['query'], $this->options);

I have the following collection named Isboo_Item :

{
"_id": ObjectId("4d3d02fec9fa877d44a36978"),
"author": null,
"backpack": null,
"itemType": 1,
"owner": "4d3cf450b532519765080000",
"place": null,
"quality": null,
"quantity": 1,
"value": null
}

I have a such PHP class :

/**

• @Document(db="Isboona", collection="Isboo_Item")
• */
  class Isboo_Item extends Isboo_Db
  {
  (...)

When I'm trying :
$dm->findOne($collection, array('_id' => $id));

I get :

Fatal error: Uncaught exception 'ReflectionException' with message 'Class 4 does not exist' in /users/developpement/www/library/Doctrine/ODM/MongoDB/Mapping/ClassMetadata.php:285

However the same works fine with another collection :

{
"_id": ObjectId("4d3cf450b532519765080000"),
"characs":

,
"name": "Krok",
"position":

,
"refFather":

,
"refMother":

}

References are not deleted when the function $dm->remove($x) is called.
It deltes $x from the database but all references are still persisted.

See function: testManyDeleteReference() in attached file.

A way to specify "inversedBy" when mapping referenceOne and referenceMany as the ORM have it.

If I try to select a couple of documents with the in() query, I receive an empty result set when the selected field is the document id.

The following code works fine and selects the right document:

       $query = $dm->createQueryBuilder("Object\Does\Not\Matter")
                   ->field("id")->equals("4d1db8ba2d8aa162300a0000")
                   ->getQuery()->execute();

Whereas the following query returns nothing:

       $query = $dm->createQueryBuilder("Object\Does\Not\Matter")
                   ->field("id")->in(array("4d1db8ba2d8aa162300a0000"))
                   ->getQuery()->execute();

After pasting down the doc tutorial example I've noticed that php hangs on
Configuration instance creation.

require 'Doctrine/Common/ClassLoader.php';
use Doctrine\Common\ClassLoader,
Doctrine\Common\Annotations\AnnotationReader,
Doctrine\ODM\MongoDB\DocumentManager,
Doctrine\ODM\MongoDB\Mongo,
Doctrine\ODM\MongoDB\Configuration,
Doctrine\ODM\MongoDB\Mapping\Driver\AnnotationDriver;
// ODM Classes
$classLoader = new ClassLoader('Doctrine\ODM', 'mongodb_odm/lib');
$classLoader->register();
// Common Classes
$classLoader = new ClassLoader('Doctrine\Common', 'mongodb_odm/lib/vendor/doctrine-common/lib');
$classLoader->register();
// Document classes
$classLoader = new ClassLoader('Documents', _DIR_);
$classLoader->register();

//-------hangs here
$config = new Configuration();

//tried explicit too
// new Doctrine\ODM\MongoDB\Configuration();

No errors or warnigs of any kind generated.

I'm using xml files to store documents annotations.
All my documents are in global namespace.

So lets say I created the following configuration file:

.Blackboard_Page.dcm.xml

<?xml version="1.0" encoding="utf-8"?>
<doctrine-mongo-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mongo-mapping" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mongo-mapping.xsd">
<document name="\Blackboard_Page" collection="blackboard.pages">
<field fieldName="_id" name="_id" id="true"/>
...
</document>
</doctrine-mongo-mapping>

When I try to get the document using the following code:

foreach($dm->createQueryBuilder("\Blackboard_Page")...>getQuery()>execute() as $page) {}

it fails with Exception "Doctrine\ODM\MongoDB\MongoDBException: No identifier/primary key specified for Document 'Blackboard_Page'. Every Document must have an identifier/primary key."

The reason of the problem is behavior of the function "get_class".
See mongodb_odm\lib\Doctrine\ODM\MongoDB\Hydrator.php line 122:
$metadata = $this->dm->getClassMetadata(get_class($document));
for details.

When the code pass an instance of the document which belongs to global namespace the function "get_class()" returns class name without "\" prefix
and AbstractFileDriver->findMappingFile convert such class name into file name without leading dot (".") (something like "Blackboard_Page.dcm.xml" instead of ".Blackboard_Page.dcm.xml").
And it causes the exception.

Patching of the method "AbstractFileDriver->findMappingFile" does not help.
The problem is more complicated than it looks like because get_class() is used in a lot of places in the code.

Recently I run ODM tests in my sandbox and found out that all collections in all databases were dropped after that.
Thanks god I did run it in my sandbox only which has own database instance.

After reviewing the code I found out that Doctrine\ODM\MongoDB\Tests\BaseTest->tearDown() method cleans up the whole MongoDB server after running the tests.

From one hand such extremely unsafe behavior is not mentioned anywhere from another hand there are no ways to work around it currently but only changing the tests code.

It would be really great if there is a way to specify MongoDB connection parameters for ODM tests or at least change tests code in order to drop only databases which were created during the test
and no others else.

Thank you.

Boolean true is returned instead of an object after a FindAndModify command is successfully executed.

$c = $dm->createQuery('downloads')
->findAndModify(array('new' => true))
>field('key')>equals('file1')
->update()
>field('counter')>inc(1)
->execute();

echo gettype($c); // boolean

There's two different error messages that can be found from this.

If it's EmbedMany in an array (not an ArrayCollection), the following error message results:

Argument 1 passed to Doctrine\ODM\MongoDB\PersistentCollection::__construct() must implement interface Doctrine\Common\Collections\Collection, array given, called in mongodb-odm/lib/Doctrine/ODM/MongoDB/UnitOfWork.php on line 1830 and defined

Otherwise it's:

Undefined index: <blank>

Failing tests have been created and a PR has been submitted on GitHub: https://github.com/doctrine/mongodb-odm/pull/230

If you have a document with a collection, during computation of the changeSet before persist a reference to that collection is placed in originalData, not a copy. Therefore, if you change the collection in an onFlush event listener, then call recomputeSingleDocumentChangeSet, the changes to the collection are not recognised, because the originalData has changed also.

I will create a test, and hopefully fix for this soon.

I tested a basic find (by id) query in Symfony and it seems that the identity map feature does not work.
here the code: https://gist.github.com/2431505

4 query with a default Doctrine ODM/Symfony configuration give me 4 query in mongostat.

array keys with dots aren't persisted for Hash field

in the attachment you will find a complete testcase.

thanks.

EDIT: use the second attachment

When I enable metadataCache:

$config->setMetadataCacheImpl(new \Doctrine\Common\Cache\ApcCache());

My custom repository stops working. For I example I have a method findAllAssoc.
witout enabling metadata cache it works fine.

Fatal error: Uncaught exception 'BadMethodCallException' with message 'Undefined method 'findAllAssoc'. The method name must start with either findBy or findOneBy!' in /data/sites/mongodb_odm/lib/Doctrine/ODM/MongoDB/DocumentRepository.php:197
Stack trace:
#0 [internal function]: Doctrine\ODM\MongoDB\DocumentRepository->__call('findAllAssoc', Array)
#1 /data/sites/cms.enkorting.nl/application/modules/user/controllers/IndexController.php(72): Doctrine\ODM\MongoDB\DocumentRepository->findAllAssoc()

Cheers, Onno

When defining a custom repository in an annotation the AnnotationDriver gives an Fatal error on line 105

Call to a member function setCustomRepositoryClass() on a non-object in /data/sites/lib/Doctrine/ODM/MongoDB/Mapping/Driver/AnnotationDriver.php on line 105

replacing:
$metadata->setCustomRepositoryClass($documentAnnot->repositoryClass);

for:
$class->setCustomRepositoryClass($documentAnnot->repositoryClass);

solves this issue..
Cheers, Onno

https://gist.github.com/72a8e30931eb56dd84bc

[15:00] <jwage> we need to write the schema file for the xml
[15:00] <jwage> and maybe expand the xml and yaml syntax
[15:00] <jwage> to have <reference
[15:00] <jwage> <embedded
[15:00] <jwage> etc
[15:00] <avalanche123> ah, I see, to make it more like ORM?
[15:01] <jwage> i think so
[15:01] <jwage> it's just better
[15:01] <jwage> you dont have to specify embedded=true
[15:01] <avalanche123> right
[15:01] <jwage> when reading in the <embedded you will just set that
[15:01] <jwage> in the array

Collections of objects in mongodb entities/documents should be handled like in the ORM through the Common collections.
This makes it possible to use similar transparent lazy-loading strategies, without $em->loadEntityAssociations which is contrary to the idea of transparent persistence.
Also this would make mongo entities/documents compatible with orm/relational entities, that is, using the same class(es) as a mongo and orm entity.

This goes for other potential upcoming projects, like couchdb, too. We should always encourage the use of the Doctrine Common collections in domain models.

We may want to reconsider the naming of things in ODM projects. I know the term "entity" is heavily overloaded but I think there might be a misunderstanding here of what @Entity refers to in the ORM. The ORM @Entity actually means a (relational) database entity (entity relationship diagram, etc...) not the "DDD" entity, of course there are many similarities.

I don't feel that comfortable with the possibility of half a dozen different "EntityManager"s, especially if they represent entirely different storage paradigms.

Remember, @Entity does not really mean "DDD entity". An EntityManager is not a "DDD entity manager" It is part of the infrastructure (persistence), not of the domain model.

Do we want X different "EntityManager"s? When considering that @Entity actually refers to a relational database entity, it would make more sense to call these things @Document in the ODM projects, since that is what they're stored as. Then we could instead use the term DocumentManager, and not EntityManager for the ODM projects.

I realize that this confusion comes from the fact that many think "entity" = "DDD entity" but that is not the case. @Entity in the ORM refers to a relational database entity just like @Column refers to a relational database column.

So my vote currently absolutely goes for @Document and DocumentManager to keep things consistent. Of course, a mongo and a couch project can both have a DocumentManager, that is fine, both storage paradigms are documents.

When running a query against a GridFS that should return no results, I expect the return value to be null (as with normal documents) instead an InvalidArgumentException is thrown, with the message "The given document has no identity".

It appears the empty result is trying to be registered as a managed document with the UOW, because MongoCollection does not return null in this case.

need to update to reflect this change http://www.doctrine-project.org/jira/browse/DCOM-17

Imagine a use case:

I have a set of classes, which extend abstract class BaseGridFsFile. All children classess are stored in same GridFs collection (using single collection inheritance).

But I cannot fetch all files from this collection, regardless their type. I know that I can use array of subclasses to fetch, but this won't work in my case, because there is no static DiscriminatorMap.

It whould be great if I could use something like this:

$files = $dm->find('BaseGridFsFile', $query);

and Doctrine would instantiate proper classes for found documents.

Is it possible?

Make ShemaManager execute an arbitrary command on selected db, to trigger actual db creation in SchemaManager::createDocumentDB/createDatabases.