[MODM-126] lessThanOrEq() renamed in lte() Created: 22/Feb/11  Updated: 22/Feb/11

Status: Open
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Documentation Priority: Minor
Reporter: Billy Bob Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The lessThanOrEq() function referenced in the documentation does not exist ay more, it was replaced by lte().

http://www.doctrine-project.org/docs/mongodb_odm/1.0/en/reference/query-builder-api.html






[MODM-123] Single Collection Inheritance : hydration won't work properly Created: 17/Feb/11  Updated: 23/Feb/11  Resolved: 23/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Blocker
Reporter: Billy Bob Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Mac OS X, MAMP



 Description   

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!



 Comments   
Comment by Jonathan H. Wage [ 18/Feb/11 ]

Hi, can you make a phpunit testcase here? https://github.com/doctrine/mongodb-odm/tree/master/tests/Doctrine/ODM/MongoDB/Tests/Functional/Ticket

Comment by Billy Bob [ 18/Feb/11 ]

Sorry but I'm not familiar with phpunit.

If that can help, I've made more tests here. Strangely when I deleted all the documents in the test base and created new ones, the hydration then worken properly! However in my real project, the issue is still here ...

In conclusion it seems that the issue is random.

Comment by Jonathan H. Wage [ 19/Feb/11 ]

I am not able to produce the issue here. Can you make a executable test that I can run so that I can see what you see?

Comment by Billy Bob [ 23/Feb/11 ]

Doesn't seem to be an issue in BETA2.





[MODM-121] a call of unknown method "setIdentifierValues" in UnitOfWork class Created: 16/Feb/11  Updated: 16/Feb/11  Resolved: 16/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: UnitOfWork
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vitaliy Kaplich Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by Jonathan H. Wage [ 16/Feb/11 ]

This is already resolve in the latest master in git.





[MODM-119] "strategy" property in @Field annotation is not recognized Created: 10/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vitaliy Kaplich Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Cent OS 5.5, PHP 5.3



 Description   

@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.

{main}

() /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



 Comments   
Comment by Jonathan H. Wage [ 11/Feb/11 ]

Fixed here https://github.com/doctrine/mongodb-odm/commit/b9bd2dcbab3c8ea2ef537fa1301525b3004ba795





[MODM-118] rename "load" method in Proxy object to "__load__" Created: 09/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Improvement Priority: Major
Reporter: Vitaliy Kaplich Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Cent OS 5.5, PHP 5.3


Issue Links:
Reference
is referenced by DDC-1029 renaming "load()" in proxy to "__load()" Resolved

 Description   

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"



 Comments   
Comment by Jonathan H. Wage [ 11/Feb/11 ]

Fixed for ODM here https://github.com/doctrine/mongodb-odm/commit/bfda83d678af1e2104ce4fba62f9dd47185b210e





[MODM-114] wrong method call in Cursor class Created: 01/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mongo, MongoCollection, MongoCursor
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Blocker
Reporter: Thomas Adam Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 11/Feb/11 ]

This is actually already fixed in the github master.





[MODM-113] No options for update queries ? Created: 31/Jan/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: JF Bustarret Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

$options are not used for update queries

=> how can we do an update(

{'multiple' => true}

) ?

 
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);


 Comments   
Comment by Jonathan H. Wage [ 11/Feb/11 ]

Fixed here https://github.com/doctrine/mongodb/commit/9511df1cede93286e8ddaa5dd00c73236fee08bd





[MODM-112] [PATCH] Allow Hydrator classes to be regenerated only if they are absent Created: 31/Jan/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Hydration
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Improvement Priority: Minor
Reporter: JF Bustarret Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: Text File autogenerate.patch     Text File autogenerate.patch    

 Description   

Hydrator classes are either never generated ou regenerated on each request.

The patch add another case : regenerate only if absent.

HydratorFactory::$autoGenerate switches to int and can have 3 values : HydratorFactory::AUTOGENERATE_NEVER, HydratorFactory::AUTOGENERATE_ALWAYS or HydratorFactory::AUTOGENERATE_ABSENT



 Comments   
Comment by Jonathan H. Wage [ 31/Jan/11 ]

Hi, I don't think this is quite right. We should make this feature match the way proxies are generated. We will need to add a console command to generate the proxies for production.

Comment by JF Bustarret [ 02/Feb/11 ]

A console command would need to know the configuration of the factories... It can't be a standalone script.

A symfony script would be great (provided it works with symfony < 2), but what about non symfony users ?

I added Proxies to my patch, and switched the two const to the Configuration class.

Comment by JF Bustarret [ 02/Feb/11 ]

Updated patch with proxies

Comment by Jonathan H. Wage [ 11/Feb/11 ]

Hi, I added the console commands for generating proxy and hydrator clases here https://github.com/doctrine/mongodb-odm/commit/56fc267459dd0b972e710b0ff1cab5fbf1859fd9

It will be integrated with DoctrineMongoDBBundle soon.





[MODM-111] Trouble with MappedSuperclass/Single collection inheritance and commit 2e8071a4dc68b027f969 Created: 28/Jan/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Closed
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Minor
Reporter: JF Bustarret Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have the following classes :

@MappedSuperClass
@InheritanceType("SINGLE_COLLECTION")
@DiscriminatorField(fieldName="_class")
@DiscriminatorMap(

{"SuperClass"="SuperClass", "SubClass1"="SubClass1", "SubClass2"="SubClass2"}

)
abstract class SuperClass {}

@Document
class SubClass1 extends SuperClass {}

@MappedSuperClass
abstract class SuperClass2 extends SuperClass {}

@Document
abstract class SubClass2 extends SuperClass2 {}

SubClass2 does not use the single collection.
SubClass1 and SubClass2 do not use the discriminator map.

This broke after commit 2e8071a4dc68b027f969.

Why can't we use MappedSuperclasses in an single collection inheritance strategy ?



 Comments   
Comment by JF Bustarret [ 31/Jan/11 ]

Dropped MappedSuperClasses and switched to Document classes.

I'm not very happy to have abstract classes configured as Document, but it works.

Comment by Jonathan H. Wage [ 11/Feb/11 ]

Hi, can you make a test case for this exposing the problem?

Comment by Jonathan H. Wage [ 11/Feb/11 ]

Ok, a mapped super class is not the top of the inheritance hierarchy. The first class that extends the mapped super class is where you would define that inheritance information.





[MODM-110] QueryBuilder missing values and values with wrong data types being inserted Created: 27/Jan/11  Updated: 19/Feb/11  Resolved: 12/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Minor
Reporter: Shards Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None

Attachments: Zip Archive Documents.zip    

 Description   

Hello,

I'm using annotation mapping for my documents and found something strange when i insert a document (having an embed document) using the query builder...

When i use the document class and persist it, things are fine:

$testCase = new \Documents\Test();
$testCase->testInt = '0';
$testCase->intfields = new \Documents\Embed\Intfields();
$testCase->intfields->intone = '1';
$testCase->intfields->inttwo = '2';
$dm->persist($testCase);
$dm->flush();

Result:
{
"_id": ObjectId("4d417fb1723014d009000008"),
"testInt": 0,
"intfields":

{ "intone": 1, "inttwo": 2 }

}

But when i use the query builder:

$dm->createQueryBuilder()
->insert('Documents\Test')
->field('testInt')->set('0')
->field('intfields.intone')->set('1')
->field('intfields.inttwo')->set('2')
->getQuery()->execute();

Result:
{
"_id": ObjectId("4d417fb1723014d009000009"),
"testInt": "0",
"intfields":

{ "inttwo": "2" }

}

Intone is missing and the values are all string values.

It seems to be a bug, but as i'm new to the doctrine and mongo world, it's more than possible to be a user error. :}

I was using the clone version of the master git hub.. is that beta2?

Regards
S.

PS.: Php files are attached



 Comments   
Comment by Jonathan H. Wage [ 11/Feb/11 ]

Hi, phpunit test case?

Comment by Jonathan H. Wage [ 12/Feb/11 ]

This is fixed now.

Comment by Shards [ 14/Feb/11 ]

thank you =}





[MODM-107] Document Manager does not delete References Created: 13/Jan/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Jan Eichhorn Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu Linux 10.04 Maveric PHP 5.3.3


Attachments: File ReferencesTest.php    

 Description   

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.



 Comments   
Comment by Jan Eichhorn [ 26/Jan/11 ]

I don't know why Billy Bob has deleted the description?
So i've restored it ....
Please don't do this without leaving a comment why!

Comment by Jonathan H. Wage [ 11/Feb/11 ]

This is fixed here https://github.com/doctrine/mongodb-odm/commit/1791da1a406d67dc32fcb72cc200ccd2cd6cb828

Thanks for the issue report!





[MODM-106] $in fails on document identifiers Created: 08/Jan/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Document Manager, Document Repositories
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Andreas Schmidt Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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();


 Comments   
Comment by Jonathan H. Wage [ 12/Jan/11 ]

This should be fixed in the latest version in github. I resolved the issues with converting the different types of query parameters

Comment by Vladimir Razuvaev [ 02/Feb/11 ]

This is not fixed actually, as there is other issue in DocumentPersister::prepareQueryValue method, unrelated to type converting.

e.g. following call will produce unexpectable result:

$result = $persister->prepareQueryValue('_id', array('$in' => array(new \MongoId('some_id'))));
// will produce new \MongoId() instead of original array

That's because prepareQueryValue always transforms value for '_id' field to scalar, even if it was originally array, containing $in.

Comment by Jonathan H. Wage [ 11/Feb/11 ]

I see better now. I fixed it here https://github.com/doctrine/mongodb-odm/commit/199cab760a7b3cc6a5050111c25e47d4788b310f





[MODM-101] Following documentation still does not produce a working bootstrap. Created: 12/Dec/10  Updated: 19/Feb/11  Resolved: 19/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Documentation Priority: Minor
Reporter: Tony R Quilkey Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows Server 2003, IIS6, PHP 5.3.4



 Description   

Setting up following the documentation found at http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/introduction/en#introduction produces the following errors.

PHP Fatal error: Class 'Doctrine\MongoDB\Configuration' not found in C:\Inetpub\sites\phpdev\public\mongodb_odm\lib\Doctrine\ODM\MongoDB\Configuration.php on line 43
PHP Stack trace:
PHP 1.

{main}

() C:\Inetpub\sites\phpdev\public\index.php:0
PHP 2. Doctrine\Common\ClassLoader->loadClass() C:\Inetpub\sites\phpdev\public\mongodb_odm\lib\vendor\doctrine-common\lib\Doctrine\Common\ClassLoader.php:0
PHP 3. require() C:\Inetpub\sites\phpdev\public\mongodb_odm\lib\vendor\doctrine-common\lib\Doctrine\Common\ClassLoader.php:148

Is there something missing from the documentation?



 Comments   
Comment by Jonathan H. Wage [ 20/Dec/10 ]

Yes, the documentation is not up to date with the latest version in git. The ODM depends on this now https://github.com/doctrine/mongodb

Comment by Jonathan H. Wage [ 19/Feb/11 ]

The docs are updated now!





[MODM-100] XmlDriver and "discriminatorMap" for "EmbedMany" Created: 09/Dec/10  Updated: 20/Dec/10  Resolved: 20/Dec/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Task Priority: Critical
Reporter: Vitaliy Kaplich Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS 5.5 PHP 5.3.3



 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 15/Dec/10 ]

It looks like it is just missing. I'd be happy to accept a patch if you can provide one





[MODM-99] ODM tests drop all collections from all databases on the MongoDB server Created: 08/Dec/10  Updated: 20/Dec/10  Resolved: 20/Dec/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Improvement Priority: Major
Reporter: Vitaliy Kaplich Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Cent OS 5.5, PHP 5.3.3



 Description   

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.






[MODM-97] FindAndModify does not return an object Created: 04/Dec/10  Updated: 20/Dec/10  Resolved: 20/Dec/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Document Manager
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Başar Aykut Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows xp sp3, apache



 Description   

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



 Comments   
Comment by Jonathan H. Wage [ 05/Dec/10 ]

The syntax using the latest version of mongodb odm in git is:

$c = $dm->createQuery('downloads')
->findAndUpdate()
->returnNew()
->field('key')->equals('file1')
->field('counter')>inc(1)
->execute();
Comment by Başar Aykut [ 06/Dec/10 ]

findAndUpdate does not return an object also however it returns an array which includes the object. Is it an expected behavior? And it does not update the record?

array(1) {
  ["4cf9163aff2e00000000154e"]=>
  object(downloads)#125 (3) {
    ["id"]=>string(24) "4cf9163aff2e00000000154e"
    ["key"] => string(6) "file1"
    ["counter"] => int(10391)
  }
}
Comment by Jonathan H. Wage [ 06/Dec/10 ]

Are you using the latest version of everything?

Comment by Başar Aykut [ 07/Dec/10 ]

I have updated to the latest version in the git. Below query works and returns the updated object as expected. However this is true only for the first call. Repeated calls return the first object .

		$pid = $dm->createQueryBuilder('downloads')
				  ->findAndUpdate()
				  ->returnNew(true)
				  ->field('key')->equals('file1')
				  ->field('counter')->inc(1)
				  ->getQuery()->execute();
Comment by Jonathan H. Wage [ 07/Dec/10 ]

Hi, I don't follow. Can you show a test of what you are doing? I did a simple test executing a findAndUpdate 2 times in a row and it worked.

Comment by Başar Aykut [ 07/Dec/10 ]

It works but it doesn't return the updated object on subsequent calls.

$pid = $dm->createQueryBuilder('downloads')
				  ->findAndUpdate()
				  ->returnNew(true)
				  ->field('key')->equals('file1')
				  ->field('counter')->inc(1)
				  ->getQuery()->execute();

var_dump($pid);

$pid = $dm->createQueryBuilder('downloads')
				  ->findAndUpdate()
				  ->returnNew(true)
				  ->field('key')->equals('file1')
				  ->field('counter')->inc(1)
				  ->getQuery()->execute();

var_dump($pid);

Outputs

object(downloads)#112 (3) {
  ["id"]=>
  string(24) "4cfadede55242b0084000003"
  ["key"]=>
  string(6) "file1"
  ["counter"]=>
  int(1)
}

object(downloads)#112 (3) {
  ["id"]=>
  string(24) "4cfadede55242b0084000003"
  ["key"]=>
  string(6) "file1"
  ["counter"]=>
  int(1)
}
// document at the beginning
{ "_id": "4cfadede55242b0084000003","key": "file1", "counter": 0 }

// after the calls
{ "_id": "4cfadede55242b0084000003","key": "file1", "counter": 2 }
Comment by Jonathan H. Wage [ 07/Dec/10 ]

Since Doctrine maintains an identity map, the 2nd time it is not refreshing the documents data. Since it already exists in the identity map it simply returns that document. You can tell Doctrine to refresh the data by doing this:

$pid = $dm->createQueryBuilder('downloads')
    ->findAndUpdate()
    ->returnNew(true)
    ->refresh(true)
    ->field('key')->equals('file1')
    ->field('counter')->inc(1)
    ->getQuery()->execute();
Comment by Başar Aykut [ 09/Dec/10 ]

I don't see any function called refresh? Are you going to add it? I think it would be better to return refreshed data automatically for the findAndUpdate command.

Comment by Jonathan H. Wage [ 13/Dec/10 ]

I added it already to the latest version in git.





[MODM-95] Persisting a document that had embedded documents prior to being removed results in a document with no embedded documents Created: 24/Nov/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Closed
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Jay Severson Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

1) Persist a document with embedded documents
2) Load document into memory (store in variable)
3) Remove document using ODM
4) Persist loaded document back to DB using ODM
5) Embedded documents are now gone

I have created a new failing test in the ODM and requested a pull



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

Thanks! Fixed in master.





[MODM-94] $or operator Created: 26/Oct/10  Updated: 15/Nov/10  Resolved: 15/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: New Feature Priority: Major
Reporter: Julien Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by Kris Wallsmith [ 01/Nov/10 ]

I've proposed a resolution in the MODM-94 branch on GitHub, what do you think?
http://github.com/doctrine/mongodb-odm/commit/428c4f3ee2b9600ad83bbe8749ebc56224ad75aa

Comment by Kris Wallsmith [ 05/Nov/10 ]

I don't seem to have permission to close this ticket...

I merged this change into master.





[MODM-93] YAML and XML mapping drivers ignore discriminatorField and discriminatorMap Created: 24/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: 1.0.0ALPHA1, 1.0.0ALPHA2, 1.0.0BETA1, 1.0.0BETA2
Fix Version/s: 1.0.0ALPHA1, 1.0.0ALPHA2, 1.0.0BETA1, 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Dan Ordille Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Symony2
Doctrine2 latest from github



 Description   

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



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

Merged! Thanks for the fix!





[MODM-92] Changing all data in embedMany collections can create duplicate embedded objects Created: 22/Oct/10  Updated: 23/Nov/10  Resolved: 23/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister, UnitOfWork
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Jeremy Mikola Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

MongoDB 1.6.3, with Mongo ODM master as of 10/22/2010



 Description   

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.



 Comments   
Comment by Jeremy Mikola [ 22/Oct/10 ]

Failing test case here: http://github.com/jmikola/mongodb-odm/commit/336a700ac6fe0cdf013fc864d8e70f43cb5b73e2
Pull request here: http://github.com/doctrine/mongodb-odm/pull/37

Temporary fix is to switch the mapping strategy to "set" instead of the default "pushPull"

I spoke with Bulat and believe the long-term fix for this will be having UoW preserve the SPL object hash of embedded objects in changsets, so that we can compare something more than arrays when deciding what MongoDB commands to utilize. For cases such as this, the $set is superfluous in my opinion - it should only be used if the same object remained in the collection and had its value(s) changed.

Comment by Jonathan H. Wage [ 23/Nov/10 ]

Thanks! This is now fixed with the refactoring we did the persisters last week!





[MODM-91] Document unnecessarily persisted when embedded documents have null properties Created: 20/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Hydration, Persister, UnitOfWork
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Ryan Weaver Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu 10.04, PHP 5.3.2, Mongo 1.6.3



 Description   

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.



 Comments   
Comment by Ryan Weaver [ 20/Oct/10 ]

Tests and fix can be found here: http://github.com/weaverryan/mongodb-odm/tree/invalid_changeset_on_null_properties

Comments on the change welcome. One unrelated test was affected, which required a fix inside BasicDocumentPersister.

Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is fixed now with the latest refactoring of some internal parts.





[MODM-90] UnitOfWork incorrectly flushes certain documents with embedded documents on first flush Created: 20/Oct/10  Updated: 20/Oct/10  Resolved: 20/Oct/10

Status: Closed
Project: Doctrine MongoDB ODM
Component/s: Hydration, Persister, UnitOfWork
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Ryan Weaver Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu, PHP 5.3.2, Mongo 1.6.3



 Description   

With documents that have embedded documents, the changeset is sometimes calculated incorrectly so that unmodified documents are flushed unnecessarily. This is similar in spirit to #MODM-83, but this isn't covered by that fix.

This can be seen when the document has an embedded document that uses a discriminator map. When calculating the changeset, the original value will have the discriminator field and value present while the actual value does not contain the discriminator field.

Covering tests with fixes to follow shortly.



 Comments   
Comment by Ryan Weaver [ 20/Oct/10 ]

The covering test and fix can be found here: http://github.com/weaverryan/mongodb-odm/tree/embedded_document_changeset_problem

Comment by Bulat Shakirzyanov [ 20/Oct/10 ]

Fixed here - http://github.com/doctrine/mongodb-odm/commit/01e02406f37a316399f4161d00b72efe43716173





[MODM-89] CLONE -UnitOfWork incorrectly updates all documents with embedded documents on flush Created: 19/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Alexander Koß Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

OS X 10.6.4, PHP 5.3.2, Mongo 1.6.3 (can reproduce on Ubuntu 8.04.4 LTS, CentOS, Win 7, etc)



 Description   

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

The complete 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:

The question with the new answer
"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.

The unkillable question
"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.



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

I don't understand the issue. Can you show some php code that shows what you are trying to persist?

Comment by Jonathan H. Wage [ 24/Nov/10 ]

I'm pretty certain this is no longer an issue.





[MODM-88] Selecting a subset of properties and then flushing causes database corruption Created: 18/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Document Manager
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Critical
Reporter: Jay Severson Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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)

{ $document->getTitle(); }

$dm->flush();
exit;



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is not a problem anymore after the recent refactoring.





[MODM-87] get_class() expects parameter 1 to be object, array given Created: 12/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Sebastian Hoitz Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 19/Oct/10 ]

Can you give the error you get? maybe the document definitions and code you're using when flushing?

Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is not a problem anymore after the recent refactoring!





[MODM-86] Order of keys in embedded document need to be enforced Created: 11/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: 1.0.0ALPHA1, 1.0.0ALPHA2, 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Improvement Priority: Major
Reporter: Bulat Shakirzyanov Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None


 Description   

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: [

{ street: 'SomeStreet', zipCode: '11111' }

,

{ zipCode: '22222', street: 'AnotherStreet' }

,
]
}
/code

then query like:

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

{ zipCode: '11111', street: 'SomeStreet' }

]}})
/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.



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is not a problem anymore after the recent refactoring!





[MODM-85] Saving a array over the top of a PersistentCollection results in duplicated data Created: 08/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Critical
Reporter: Andy Stanberry Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Mongo 1.6.1, opensky/mongo-odm/master



 Description   

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.



 Comments   
Comment by Sebastian Hoitz [ 12/Oct/10 ]

Are you using the most recent version of Doctrine MongoDB ODM?

I'm asking because there was a bug fix for something where all embedded documents were duplicated.

However I'm also currently investigating a bug where in some cases only one entry does not get removed (although $pullAll is called correctly).

Comment by Jonathan H. Wage [ 19/Oct/10 ]

Bulat, this is the same issue where PersistentCollection is never initialized so thats why the array_diff always appends the data with a $pushAll. Remember we talked about it? we can fix it just need to chat about it for a bit.

Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is not a problem anymore after the recent refactoring!





[MODM-84] prePersist and postPersist called twice Created: 06/Oct/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Events
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Jay Severson Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 08/Oct/10 ]

I tried to setup a test for this but could not replicate it.

Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is fixed now as well.





[MODM-81] No reference to a loaded document if proxy id = document id Created: 28/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: UnitOfWork
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Blocker
Reporter: Thomas Adam Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 04/Oct/10 ]

Can I see a test case?

Comment by Thomas Adam [ 05/Oct/10 ]

test case: http://github.com/tecbot/mongodb-odm/commit/df4e3102b4b29f7e7ad6aa24800457b52f93b14d

Comment by Jonathan H. Wage [ 24/Nov/10 ]

Thanks! This is fixed now. The reference will now be the same instance as the root document itself instead of another instance of the same document.





[MODM-80] Changeset for embedded documents calculates to an unnecessary pullAll() and pushAll() in some cases. Created: 20/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: 1.0.0BETA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Ryan Weaver Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is not a problem anymore after the recent refactoring!





[MODM-79] Referenced and Embedded document duplicates are inserted Created: 13/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Sebastian Hoitz Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None


 Description   

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.



 Comments   
Comment by Alexander Koß [ 15/Sep/10 ]

i have the same problem.
when i flush persistant data i get duplicated entries.

$this->_dm->persist($Opinion);
$this->_dm->flush();

Comment by Ryan Weaver [ 20/Sep/10 ]

I believe I'm replicating this issue and have a test case for it here: http://github.com/weaverryan/mongodb-odm/commit/9968697a2c07e31ecfdd8d55ecbf9bf39183d01e

The second test case, testReplaceEntireGroupsArray() displays the above error. The update contains a pushAll() for the one embedded document that remains, but no pullAll() to remove the embedded documents that no longer exist.

The first test case, testModifyGroupsArrayDirectly() tests for a different, related issue. I'll open a separate ticket for it.

Thanks

Comment by Sebastian Hoitz [ 20/Sep/10 ]

It looks like the changeset is calculated correctly.
So there must be a fault afterwards.

Maybe it has to do with MongoDB's limitation of just sending one atomic operator on one field at a time?

Can we use a $set on a collection? Or don't we do this because we would also re-send unmodified entries?

Comment by Sebastian Hoitz [ 22/Sep/10 ]

This commit fixed the issue for me:

http://github.com/doctrine/mongodb-odm/commit/6b78658b74507edafc59f0ff004d51d6be0e45f5

Thanks @jwage

Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is for sure fixed now with our recent refactoring.





[MODM-77] Add "addToSet" strategy for collections / embedMany / referenceMany Created: 13/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Improvement Priority: Major
Reporter: Vladimir Razuvaev Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None


 Description   

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?



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

Sure, it was simple to add. If you specify $addToSet now it will use that instead of $pushAll to add insert new elements in a collection.





[MODM-75] mappedSuperclass and embedded document not working with yaml mapping Created: 10/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: julien rollin Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

mappedSuperclass
#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

InheritedClass
#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

embeddedDocument
#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



 Comments   
Comment by julien rollin [ 10/Sep/10 ]

if i call

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

properties createdAt and updatedAt are saved to contact document only

if i call

$dm->persist($program);
$dm->persist($contact);
$dm->flush();

properties createdAt and updatedAt are saved to contact and embedded documents.

So is it the "cascade: all" property the problem ?

Comment by Jonathan H. Wage [ 10/Sep/10 ]

Are you using the absolute latest version from git? we made some changes recently to cascading and embedded documents. It is not necessary anymore to specify any cascading options as it does not make sense for embedded documents. it should and does cascade by default now for embedded documents.

Comment by julien rollin [ 10/Sep/10 ]

yes i use the remote origin/master (i just did an update to de2e671201ef5a97e2a970f35cc94b5ad3590bb5)

but actually, since your my comments and after yours, i got this beautiful fatal error (unknown before )

Fatal error: Class Doctrine\ODM\MongoDB\Query\Lexer contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Doctrine\Common\Lexer::_getType) in D:\web\php\doctrine2-mongodb\lib\Doctrine\ODM\MongoDB\Query\Lexer.php on line 33

edit : rechecking all dependencies (doctrine/common, etc )

edit 2 : last checkout resolved cascade persist





[MODM-74] lifecycleCallbacks are not inherited from mappedSuperclass in yaml mapping Created: 10/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: julien rollin Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

The abstract class :

abstract class Cgd\DomainObject\DomainObjectAbstract

mappedSuperclass
#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

InheritedClass
#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



 Comments   
Comment by julien rollin [ 10/Sep/10 ]

fixed in current master branch





[MODM-72] New property 'options' in Annotations Created: 06/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: New Feature Priority: Minor
Reporter: Stefan Riehl Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

It would be great for many purposes to add a property options to document annotations like this:

/** @Field(type="mytype", options={}) */

the options should also be implemented in the MetadataClass.

See also discussion:
http://groups.google.de/group/doctrine-user/browse_thread/thread/71d29b8284beee86



 Comments   
Comment by Jonathan H. Wage [ 24/Nov/10 ]

Fixed here https://github.com/doctrine/mongodb-odm/commit/16e0ac113c557c1fb73e3f31eec93176ad5992a1





[MODM-70] Updates of documents after read Created: 02/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Closed
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Blocker
Reporter: Thomas Adam Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None
Environment:

Mongodb 1.6 (64-bit + Google V8)


Attachments: File MODM70Test.php    
Issue Links:
Duplicate
is duplicated by MODM-66 Bug when persisting referenced collec... Resolved

 Description   

When I save a document and then read it again updated the document with the initial values.

The following log output when saving Doctrine:

Array
(
    [storing] => 1
    [file] => /app/tests/cases/models/asset/test.swf
    [document] => Array
        (
            [filename] => a3f06b4b882ee28ee8d8c7a5e6ab67e6.swf
            [php] => ass
        )

    [class] => Documents\Assets\Asset
    [db] => test
    [collection] => assets_files
)

Array
(
    [batchInsert] => 1
    [num] => 1
    [data] => Array
        (
            [00000000341a62a40000000001574585] => Array
                (
                    [cS] => 3
                    [rS] => 3
                    [co] => 0
                    [ca] => 0
                    [lvl] => 0
                    [nb] => 0
                    [sex] => 0
                    [na] => Building01
                    [typ] => building
                    [as] => Array
                        (
                            [$ref] => assets_files
                            [$id] => MongoId Object
                                (
                                )

                            [$db] => test
                        )

                )

        )

    [class] => Documents\Assets\MapAsset
    [db] => test
    [collection] => map_assets
)

Then read:

Array
(
    [findOne] => 1
    [query] => Array
        (
            [_id] => MongoId Object
                (
                )

        )

    [fields] => Array
        (
        )

    [class] => Documents\Assets\MapAsset
    [db] => test
    [collection] => map_assets
)

Then check for updates Document:

$this->dm->getUnitOfWork()->computeChangeSets();
$update = $this->dm->getUnitOfWork()->getDocumentPersister('Documents\Assets\MapAsset')->prepareUpdateData($mapAsset);
print_r($update);

Array
(
    [$set] => Array
        (
            [cS] => 3
            [rS] => 3
            [co] => 0
            [ca] => 0
            [lvl] => 0
            [nb] => 0
            [sex] => 0
            [na] => Building01
            [typ] => building
            [as] => Array
                (
                    [$ref] => assets_files
                    [$id] => MongoId Object
                        (
                        )

                    [$db] => test
                )

        )

)

Why is there an update even though it set the initial values? In Mongo are the values set correctly!

Then I run a flush:

Array
(
    [update] => 1
    [criteria] => Array
        (
            [_id] => MongoId Object
                (
                )

        )

    [newObj] => Array
        (
            [$set] => Array
                (
                    [uploadDate] => 0.63800000 1283421657
                    [length] => 4222
                    [chunkSize] => 262144
                    [md5] => 2af70cb102026bde0cf9f181780b642c
                )

        )

    [options] => Array
        (
        )

    [class] => Documents\Assets\Asset
    [db] => test
    [collection] => assets_files
)

Array
(
    [update] => 1
    [criteria] => Array
        (
            [_id] => MongoId Object
                (
                )

        )

    [newObj] => Array
        (
            [$set] => Array
                (
                    [cS] => 3
                    [rS] => 3
                    [co] => 0
                    [ca] => 0
                    [lvl] => 0
                    [nb] => 0
                    [sex] => 0
                    [na] => Building01
                    [typ] => building
                    [as] => Array
                        (
                            [$ref] => assets_files
                            [$id] => MongoId Object
                                (
                                )

                            [$db] => test
                        )

                )

        )

    [options] => Array
        (
        )

    [class] => Documents\Assets\MapAsset
    [db] => test
    [collection] => map_assets
)

1st Doctrine update GridFS file and destroyed it! Wrong value for uploadDate and the file can then be displayed in the browser no longer!

2nd Why did he updatet The Document with the same values that are already there in Mongo and the initial values are?

Here is my test code:

$asset = APP_TEST_CASES . DS . 'models' . DS . 'asset' . DS . 'test.swf';
$assetInfo = pathinfo($asset);
$assetName =  md5($assetInfo['basename'] . time() . mt_rand()) . '.' . $assetInfo['extension'];
$assetFile = new Documents\Assets\Asset($asset, $assetName);

$cSpan = 3;
$rSpan = 3;
$mapAsset = new Documents\Assets\MapAsset('Building01', 'building', $cSpan, $rSpan, null, $assetFile);
$this->assertEqual($mapAsset->getColumnSpan(), $cSpan);
$this->assertEqual($mapAsset->getRowSpan(), $rSpan);
$this->assertEqual($mapAsset->getSpans(), array('columnSpan' => $cSpan, 'rowSpan' => $rSpan));

$this->dm->persist($mapAsset);
$this->dm->flush();
$this->dm->refresh($mapAsset);

$this->dm->getUnitOfWork()->computeChangeSets();
$update = $this->dm->getUnitOfWork()->getDocumentPersister('Documents\Assets\MapAsset')->prepareUpdateData($mapAsset);
debug($update);
$this->dm->flush();

Here is my test Documents:

namespace Documents\Assets;

/**
 * @Document(collection="assets_files")
 */
class Asset {
	/**
	 * @Id
	 * @var string
	 */
	protected $_id;
	/**
	 * @File
	 */
	protected $_file;
	/**
	 * @String(name="filename")
	 */
	protected $_filename;
	/**
	 * @Field(name="uploadDate")
	 * @var int
	 */
	protected $_uploadDate;
	/**
	 * @Field(name="length")
	 * @var int
	 */
	protected $_length;
	/**
	 * @Field(name="chunkSize")
	 * @var int
	 */
	protected $_chunkSize;
	/**
	 * @Field(name="md5")
	 * @var string
	 */
	protected $_md5;
	/**
	 * @Field(name="contentType")
	 * @var string
	 */
	protected $_contentType;
	/**
	 * @Field(name="metadata")
	 * @var string
	 */
	protected $_metadata;

	public function __construct($file, $filename = null) {
		$this->_file = $file;
		$this->_filename = $filename;
	}
	
	// ..
}

namespace Documents\Assets;

/**
 * @Document(collection="map_assets")
 */
class MapAsset {
	/**
	 * @Id
	 * @var string
	 */
	protected $_id;

	/**
	 * @ReferenceOne(
	 *	targetDocument="Documents\Assets\Asset",
	 *	name="as",
	 *	cascade={"persist", "remove"}
	 *	)
	 * @var Documents\Assets\Asset
	 */
	protected $_asset;

	// ..
}


 Comments   
Comment by Thomas Adam [ 02/Sep/10 ]

I have just seen. The read out after each of the Documents with the same values updated!

$user = $this->dm->findOne('Documents\User', array('snu.id' => (int) $snid)); //, array('snu.friends' => false));
$this->dm->getUnitOfWork()->computeChangeSets();
$update = $this->dm->getUnitOfWork()->getDocumentPersister('Documents\User')->prepareUpdateData($user);
print_r($update); die();

print all values!!!!

Comment by Jonathan H. Wage [ 02/Sep/10 ]

Hi, can you make a simplified phpunit test case?

Comment by Thomas Adam [ 02/Sep/10 ]

I've just seen the MODM-66 is exactly the same errors.
It is the initial value after a refresh or read at a subsequent flush again highlighted as an update and it is doubly in Mongo!

I can not just create a test case.

Comment by Jonathan H. Wage [ 02/Sep/10 ]

Thanks, I see it is the same issue in MODM-66. We'll have a look and see what is wrong. Thanks, Jon

Comment by Thomas Adam [ 06/Sep/10 ]

Test Case Added

Comment by Bulat Shakirzyanov [ 06/Sep/10 ]

should be fixed here http://github.com/doctrine/mongodb-odm/tree/MODM-70, Jon please review.
The issue was cause due to the fact, that after hydration in UnitOfWork::getOrCreateDocument() we used the resultset from mongo as originalDocumentData, which in case field names were different from document properties led to wrong changeset calculation

Comment by Thomas Adam [ 06/Sep/10 ]

Fantastic! it works. Many many thanks

Comment by Sebastian Hoitz [ 07/Sep/10 ]

I can also say that it works. This should be resolved.

Comment by Thomas Adam [ 10/Sep/10 ]

When it is added into the master branch?

Comment by Jonathan H. Wage [ 24/Nov/10 ]

This is fixed now due to some other refactoring we did. Committed test here https://github.com/doctrine/mongodb-odm/commit/bfe54c52ac242181392c6c8f9af04c9885b53db8 and it is passing. Thanks!





[MODM-69] implement commands to generate documents Created: 31/Aug/10  Updated: 12/Feb/11  Due: 06/Sep/10  Resolved: 12/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0ALPHA1, 1.0.0ALPHA2, 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: New Feature Priority: Major
Reporter: Bulat Shakirzyanov Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Jonathan H. Wage [ 12/Feb/11 ]

https://github.com/doctrine/mongodb-odm/commit/e2b7c35d9baa8444c62348c4132dc6bbb276114d





[MODM-68] port EntityGenerator to DocumentGenerator Created: 31/Aug/10  Updated: 12/Feb/11  Due: 06/Sep/10  Resolved: 12/Feb/11

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0ALPHA1, 1.0.0ALPHA2, 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: New Feature Priority: Major
Reporter: Bulat Shakirzyanov Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Jonathan H. Wage [ 12/Feb/11 ]

Fixed here https://github.com/doctrine/mongodb-odm/commit/e2b7c35d9baa8444c62348c4132dc6bbb276114d





[MODM-66] Bug when persisting referenced collection Created: 31/Aug/10  Updated: 06/Sep/10  Resolved: 06/Sep/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vladimir Razuvaev Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Duplicate
duplicates MODM-70 Updates of documents after read Closed

 Description   

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
        )

)


 Comments   
Comment by Bulat Shakirzyanov [ 03/Sep/10 ]

here is a test case for it http://pastie.org/1136303

Comment by Bulat Shakirzyanov [ 03/Sep/10 ]

Jon, fixed here http://github.com/doctrine/mongodb-odm/tree/MODM-66
Please review and resolve jira if everything is ok
As soon as the jira is resolved, I'll merge it in master

Comment by Thomas Adam [ 03/Sep/10 ]

Error is not resolved!
Wrong test case. Test case should properly be so.
are dm->refresh before the next flush. For there do it again a double entry!

$b1 = new B('first');
$a = new A(array($b1));
$this->dm->persist($a);
$this->dm->flush();
$b2 = new B('second');

$this->dm->refresh($a); // !!!!!!!!

$a->getB()->add($b2);
$this->dm->flush(); // He now adds the initial values there too. Thus, the array first, first and second!

// $this->dm->refresh($a);
$b = $a->getB()->toArray();

$this->assertEquals(2, count($b));

$this->assertEquals(array(
	$b1->getId(), $b2->getId()
), array(
	$b[0]->getId(), $b[1]->getId()
));
Comment by Bulat Shakirzyanov [ 03/Sep/10 ]

looking into it

Comment by Bulat Shakirzyanov [ 03/Sep/10 ]

should be fixed here http://github.com/doctrine/mongodb-odm/commits/MODM-66, please test and provide feedback

Comment by Thomas Adam [ 03/Sep/10 ]

So the test is working now.

But in my documents the problem persists!
Here is my test document:

namespace Documents\Avatar;

/**
 * @Document(collection="avatars")
 */
class Avatar {

	/**
	 * @Id
	 */
	protected $_id;
	/**
	 * @String(name="na")
	 * @var string
	 */
	protected $_name;
	/**
	 * @int(name="sex")
	 * @var int
	 */
	protected $_sex;
	/**
	 * @EmbedMany(
	 *	targetDocument="Documents\Avatar\AvatarPartTest",
	 *	name="aP"
	 * )
	 * @var array Documents\Avatar\AvatarPartTest
	 */
	protected $_avatarParts;

	/**
	 * Constructor
	 * @param string $name
	 * @param int $sex
	 */
	public function __construct($name, $sex, $avatarParts = null) {
		$this->_name = $name;
		$this->_sex = $sex;
		$this->_avatarParts = $avatarParts;
	}

	/**
	 * @return string
	 */
	public function getId() {
		return $this->_id;
	}

	/**
	 * @return string
	 */
	public function getName() {
		return $this->_name;
	}

	/**
	 * @param string $name
	 */
	public function setName($name) {
		$this->_name = $name;
	}

	/**
	 * @return int
	 */
	public function getSex() {
		return $this->_sex;
	}

	/**
	 * @param int $sex
	 */
	public function setSex($sex) {
		$this->_sex = $sex;
	}

	/**
	 * @return array Documents\Avatar\AvatarPartTest
	 */
	public function getAvatarParts() {
		return $this->_avatarParts;
	}

	/**
	 * @param Documents\Avatar\AvatarPartTest $part
	 */
	public function addAvatarPart($part) {
		$this->_avatarParts[] = $part;
	}

	/**
	 * @param array Documents\Avatar\AvatarPartTest $parts
	 */
	public function setAvatarParts($parts) {
		$this->_avatarParts = $parts;
	}

	/**
	 * @param Documents\Avatar\AvatarPartTest $part
	 */
	public function removeAvatarPart($part) {
		$key = array_search($this->_avatarParts, $part);
		if ($key !== false) {
			unset($this->_avatarParts[$key]);
		}
	}

}

namespace Documents\Avatar;

/**
 * @EmbeddedDocument
 */
class AvatarPartTest {
	/**
	 * @String(name="col")
	 * @var string
	 */
	protected $_color;

	/**
	 * Constructor
	 * @param string $type
	 * @param string $color
	 */
	public function __construct($color = null) {
		$this->_color = $color;
	}

	/**
	 * @return string
	 */
	public function getColor() {
		return $this->_color;
	}

	/**
	 * @param string $color
	 */
	public function setColor($color) {
		$this->_color = $color;
	}

}

And here is my test code:

$part = new Documents\Avatar\AvatarPartTest();
$avatar = new Documents\Avatar\Avatar('Test', 1, array($part));
$this->dm->persist($avatar);
$this->dm->flush();
$this->dm->refresh($avatar);

$this->dm->getUnitOfWork()->computeChangeSets();
$update = $this->dm->getUnitOfWork()->getDocumentPersister('Documents\Avatar\Avatar')->prepareUpdateData($avatar);
print_r($update);
// print :
Array
(
    [$set] => Array
        (
            [na] => Test
            [sex] => 1
        )
    [$pushAll] => Array
        (
            [aP] => Array
                (
                    [0] => Array
                        (
                        )
                )
        )
)
// That is wrong because it priced the initial values are!

$this->dm->flush();

And this is the log:

// First insert
Array
(
    [batchInsert] => 1
    [num] => 1
    [data] => Array
        (
            [0000000061fd6eaa00000000066fdfcd] => Array
                (
                    [na] => Test
                    [sex] => 1
                    [aP] => Array
                        (
                            [0] => Array
                                (
                                )
                        )
                )
        )
    [class] => Documents\Avatar\Avatar
    [db] =>test
    [collection] => avatars
)

// Refresh findOne

// The last flush after refresh
// I have made no updates yet he wants to save the entire document again!

Array
(
    [update] => 1
    [criteria] => Array
        (
            [_id] => MongoId Object
                (
                )
        )
    [newObj] => Array
        (
            [$set] => Array
                (
                    [na] => Test
                    [sex] => 1
                )
        )
    [options] => Array
        (
        )
    [class] => Documents\Avatar\Avatar
    [db] => test
    [collection] => avatars
)

Array
(
    [update] => 1
    [criteria] => Array
        (
            [_id] => MongoId Object
                (
                )
        )
    [newObj] => Array
        (
            [$pushAll] => Array
                (
                    [aP] => Array
                        (
                            [0] => Array
                                (
                                )
                        )
                )
        )
    [options] => Array
        (
        )
    [class] => Documents\Avatar\Avatar
    [db] => test
    [collection] => avatars
)
Comment by Vladimir Razuvaev [ 04/Sep/10 ]

Still getting same error with example from original post (after odm update).

Comment by Bulat Shakirzyanov [ 05/Sep/10 ]

The fix was in the MODM-66 branch, it is merged now into master, please re-try and confirm you are still getting an error

Comment by Vladimir Razuvaev [ 05/Sep/10 ]

Yes, it is fixed now. Thanks a lot!

Comment by Thomas Adam [ 06/Sep/10 ]

The upper test works, but not my test!
Please test my written test earlier in a comment. Test documents are part of it!

And:

$this->dm->getUnitOfWork()->computeChangeSets();
$update = $this->dm->getUnitOfWork()->getDocumentPersister('Documents\Avatar\Avatar')->prepareUpdateData($avatar);

still shows all the variables in it are already in Mongo!
According to flush all variables reset or push out!

Comment by Bulat Shakirzyanov [ 06/Sep/10 ]

resolved

Comment by Thomas Adam [ 06/Sep/10 ]

So I recorded all the updates, but my test document still does not work. The test for
this ticket is working, but not the test of my comment. Did they not make the mistake that he is a
push with initial values and sets makes name and gender again? Please give me an answer.
With this error is useless for me odm, because I can save anything, because everything in there twice
stands. There are also variables Increments etc.

Comment by Bulat Shakirzyanov [ 06/Sep/10 ]

Thomas, the MODM-70 ticket is still open
Jon, can you please remove related to MODM-70, so that we don't confuse Thomas.
I am working on that ticket.

Comment by Bulat Shakirzyanov [ 06/Sep/10 ]

Thomas, it would help me very much if you created a phpunit test case that fails.

Comment by Thomas Adam [ 06/Sep/10 ]

Ok. I added a PHPUnit test case in MODM-70.
I hope this helps.





[MODM-65] EmbeddedDocument - Incorrect assignment of special field names on save Created: 30/Aug/10  Updated: 30/Aug/10  Resolved: 30/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Critical
Reporter: Thomas Adam Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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
        )
)



 Comments   
Comment by Jonathan H. Wage [ 30/Aug/10 ]

So, basically the name attribute is not being used on embedded documents?

Comment by Thomas Adam [ 30/Aug/10 ]

Correct. But when read out of data it is used the name attribute.

Comment by Jonathan H. Wage [ 30/Aug/10 ]

Fixed here http://github.com/doctrine/mongodb-odm/commit/3331a91fc628cc2196bcbdc4bbed91d6faa743d3

Thanks, Jon





[MODM-63] More errors when persisting gridfs files Created: 28/Aug/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vladimir Razuvaev Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 30/Aug/10 ]

We'll need a test case, always. Or atleast some kind of pasted code that I can use to produce the issue.

Comment by Jonathan H. Wage [ 30/Aug/10 ]

Can you just paste the code that causes the error? Like you have done in previous issues. I can't seem to replicate this one.

Comment by Vladimir Razuvaev [ 31/Aug/10 ]

I've found a case when it happens. It is an exceptional situation when someone is trying to persist file without property $file being set.

E.g. the case:

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

    /** @File */
    protected $file; // note, file is not set

    /** @String */
    protected $c = 'tmp';
}

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

This test case produces notices and warnings. My guess is that it should end up with Exception?

Comment by Jonathan H. Wage [ 24/Nov/10 ]

This should be fixed now.





[MODM-62] PHP warning when array is replaced with ArrayCollection: array_udiff_assoc(): Argument #2 is not an array Created: 28/Aug/10  Updated: 30/Aug/10  Resolved: 30/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vladimir Razuvaev Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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


 Comments   
Comment by Jonathan H. Wage [ 30/Aug/10 ]

Thanks, fixed in http://github.com/doctrine/mongodb-odm/commit/c12c9239cf152b4764da07b2bc89bfc6967a9569





[MODM-61] GridFs file is stored incorrectly after two flushes Created: 27/Aug/10  Updated: 30/Aug/10  Resolved: 30/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vladimir Razuvaev Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 30/Aug/10 ]

Fixed by http://github.com/doctrine/mongodb-odm/commit/e8945bc53b59e8c8b8c0b13df0b73a8774c7111b





[MODM-59] Exception: "The given document has no identity." when findOne query returns none from a MongoGridFs Created: 25/Aug/10  Updated: 26/Aug/10  Resolved: 26/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Mongo, MongoCollection, MongoCursor
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Scott Aubrey Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Scott Aubrey [ 25/Aug/10 ]

Issue fixed in my git hub branch

scottaubrey / mongodb-odm @ MODM-59
git@github.com:scottaubrey/mongodb-odm.git

pull request sent

(sorry not sure how much of this I'm meant to mention here, my first contribution with git and github)

Comment by Bulat Shakirzyanov [ 26/Aug/10 ]

http://github.com/doctrine/mongodb-odm/commit/e677f64004b9bc900bfc8f098b15eb24dc3d5262





[MODM-58] Update Collection API Created: 24/Aug/10  Updated: 27/Aug/10  Resolved: 27/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Collections, Mongo, MongoCollection, MongoCursor
Affects Version/s: 1.0.0ALPHA1, 1.0.0ALPHA2, 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Improvement Priority: Major
Reporter: Bulat Shakirzyanov Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by Bulat Shakirzyanov [ 26/Aug/10 ]

http://github.com/doctrine/mongodb-odm/commit/e46ec823bb1b2b463f4931a0cadfe6c6bd39286d

Comment by Bulat Shakirzyanov [ 26/Aug/10 ]

fix typo and add test

Comment by Bulat Shakirzyanov [ 27/Aug/10 ]

http://github.com/doctrine/mongodb-odm/commit/298b72378d829c5b7010273981b23fb7f9882d89





[MODM-57] The SchemaManager::createDocumentDB/createDatabases Created: 23/Aug/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Bulat Shakirzyanov Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by Bulat Shakirzyanov [ 24/Aug/10 ]

http://github.com/doctrine/mongodb-odm/commit/87dfe45ac63818e5a274744bfb46abe63c4fb36d





[MODM-56] @PreUpdate & EmbedMany Created: 22/Aug/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: 1.0.0ALPHA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: D Ashwood Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP 5.3.2+, Mongodb, recent (varies by developer but all experiencing the same issue)



 Description   
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
// Article
namespace Bundle\ArticleBundle\Document;

use Bundle\CommentBundle\Document\Comment;
use Bundle\ExerciseCommonBundle\Document\Repository;

/**
 * @Document(
 *   collection="article",
 *   indexes={
 *     @Index(keys={"createdAt"="asc"})
 *   },
 *   repositoryClass="Bundle\ArticleBundle\Document\ArticleRepository"
 * )
 * @HasLifecycleCallbacks
 */
class Article
{
    /**
     * @Id
     */
    protected $id;
    /**
     * @ReferenceOne(targetDocument="Bundle\AccountBundle\Document\User")
     */
    protected $user;
    /**
     * @ReferenceOne(targetDocument="Bundle\ArticleBundle\Document\ArticleCategory")
     * @Validation({
     *      @NotBlank (message="Please select a category.")
     * })
     */
    protected $category;
    /**
     * @Field(type="string")
     */
    protected $slug;
    /**
     * @Field(type="string")
     * @Validation({
     *      @NotBlank (message="You forgot a Title?"),
     *      @MinLength(limit=4, message="Just a little too short.")
     * })
     */
    protected $title;
    /**
     * @Field(type="string")
     * @Validation({
     *      @NotBlank (message="Please summarize your article."),
     *      @MinLength(limit=100, message="Not long enough!"),
     *      @MaxLength(limit=200, message="A wee bit too long.")
     * })
     */
    protected $summary;
    /**
     * @Field(type="string")
     * @Validation({
     *      @NotBlank (message="Where's the beef?")
     * })
     */
    protected $body;
    
	/** 
	 * @EmbedMany(targetDocument="Bundle\CommentBundle\Document\Comment") 
	 * */
	protected $comments = array();
	
    /**
     * @Field(type="boolean")
     */
    protected $published = false;
    /**
     * @Field(type="date", nullable=false)
     */
    protected $createdAt;
    /**
     * @Field(type="date", nullable=false)
     */
    protected $updatedAt;

    public function getId()
    {
        return $this->id;
    }

    public function isNew() {
        return empty($this->id);
    }

    public function getUser()
    {
        return $this->user;
    }

    public function getCategory()
    {
        return $this->category;
    }

    public function getSlug()
    {
        return $this->slug;
    }

    public function setSlug($slug)
    {
        $this->slug = $slug;
    }

    public function setUniqueSlug()
    {
        $this->slug = Repository::Slugify($this->title);
    }

    public function isPublished()
    {
        if($this->published) {
            return true;
        }
        return false;
    }

    public function publish()
    {
        $this->published = true;
    }

    public function unpublish()
    {
        $this->published = false;
    }

    public function getSummary()
    {
        return $this->summary;
    }

    public function setSummary($summary)
    {
        $this->summary = $summary;
    }

    public function getTitle()
    {
        return $this->title;
    }

    public function setTitle($title)
    {
        $this->title = $title;
    }

    public function getBody()
    {
        return $this->body;
    }



    public function setBody($body)
    {
        $this->body = $body;
    }

    public function setUser($user) {
        $this->user = $user;
    }

    public function setCategory($category) {
        $this->category = $category;
    }

    public function getCreatedAt()
    {
        return $this->createdAt;
    }

    /**
     * It can be useful when writing fixtures
     * @param \DateTime $date
     * @return void
     */
    public function setCreatedAt(\DateTime $date)
    {
        $this->createdAt = $date;
    }

    public function getUpdatedAt()
    {
        return $this->updatedAt;
    }

    public function __toString()
    {
        return $this->title();
    }
    
    
	/**
	 * @return the $comments
	 */
	public function getComments() {
		return $this->comments;
	}    
    
	/**
	 * @param $comments the $comments to set
	 */
	public function setComments($comments) {
		$this->comments = $comments;
	}
    /** @PrePersist */
    public function incrementCreatedAt()
    {
        if(null === $this->createdAt) {
            $this->createdAt = new \DateTime();
        }
        $this->updatedAt = new \DateTime();
    }

    /** @PreUpdate */
    public function incrementUpdatedAt() {
        $this->updatedAt = new \DateTime();
    }

    public function fromArray(array $array)
    {
        foreach($array as $property => $value) {
            $this->$property = $value;
        }
    }
}
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
// Comment
<?php

namespace Bundle\CommentBundle\Document;

/**
 * @EmbeddedDocument
 */
class Comment
{
	
	/**
     * @Id
     */
    protected $id;
	
    /**
     * @Field(type="date", nullable=true)
     */
    protected $createdAt;

    /**
     * @Field(type="string", nullable=true)
     */
    protected $message;

    /**
     * @ReferenceOne(targetDocument="Bundle\AccountBundle\Document\User")
     */
    protected $user;

    /**
     * @return the $createdAt
     */
    public function getCreatedAt() {
        return $this->createdAt;
    }

    /**
     * @return the $message
     */
    public function getMessage() {
        return $this->message;
    }

    /**
     * @return the $user
     */
    public function getUser() {
        return $this->user;
    }

    /**
     * @param $createdAt the $createdAt to set
     */
    public function setCreatedAt($createdAt) {
        $this->createdAt = $createdAt;
    }

//    /** @PrePersist */
//    public function incrementCreatedAt()
//    {
//        if(null === $this->createdAt) {
//            $this->createdAt = new \DateTime();
//        }
//        $this->updatedAt = new \DateTime();
//    }
//
//    /** @PreUpdate */
//    public function incrementUpdatedAt() {
//        $this->updatedAt = new \DateTime();
//    }

    /**
     * @param $message the $message to set
     */
    public function setMessage($message) {
        $this->message = $message;
    }

    /**
     * @param $by_user_id the $by_user_id to set
     */
    public function setUser($user) {
        $this->user = $user;
    }
}
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
                $article = $this->odm->getRepository('Bundle\ArticleBundle\Document\Article')->find("someID");

		$newComment = new Comment();
		$newComment->setUser($user);
		$newComment->setMessage("PPPPOOOOOPPPP");
		$newComment->setCreatedAt(new \DateTime());
		
		$comments = $article->getComments();
		$comments[] = $newComment;
		$article->setComments($comments);
		
		$this->odm->persist($article);
                // With or without the args to flush
		$this->odm->flush(array('safe' => true));

With the above - no exception or error is thrown. It appears that the comment is added - but checking the collection in mongo and there's nothing added to the document.
Removing the PreUpdate on the Article method allows the embedded document to be saved into Article.



 Comments   
Comment by Jonathan H. Wage [ 23/Aug/10 ]

Hi, can you provide a consolidated PHPUnit test case?

Comment by D Ashwood [ 23/Aug/10 ]

Just to clarify:

$parent = new ParentDocument();
$odm->persist($parent);
$odm->flush();

// count(parent->getChildren() ) = 0

// Add some children
$childOne = new childEmbededDocument();

$children = $parent->getChildren();
$children[] = $childOne;
$parent->setChildren($children);
$odm->persist($parent);

$childTwo = new childEmbededDocument();

$children = $parent->getChildren();
$children[] = $childTwo;
$parent->setChildren($children);
$odm->persist($parent);

// Results
// When $parent has lifeCycle callbacks - specifically @PreUpdate - count(parent->getChildren() ) = 0
// When $parent doesn't have lifeCycle callbacks - count(parent->getChildren() ) = 2

So the issue isn't so much about lifeCycle cascading to the children - it's that the parent lifeCycle callback @PreUpdate affects adding embedded children.

Comment by Jonathan H. Wage [ 23/Aug/10 ]

I am still not clear on what the problem is Jay said you were trying to use lifecycle callbacks on embedded documents which is not supported. You all seem to be talking about 2 different things?

Comment by Jonathan H. Wage [ 23/Aug/10 ]

Fixed by http://github.com/doctrine/mongodb-odm/commit/faf85a281b1562d184b44261a6e4dcdb13e03c5e

Comment by Jonathan H. Wage [ 24/Aug/10 ]

The callbacks will also work on embedded documents now.





[MODM-55] Extract SchemaManager from DocumentManager Created: 19/Aug/10  Updated: 23/Aug/10  Resolved: 23/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Document Manager
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Improvement Priority: Major
Reporter: Bulat Shakirzyanov Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Bulat Shakirzyanov [ 23/Aug/10 ]

finished here http://github.com/doctrine/mongodb-odm/commit/231dc888be3673658254aad3946e04440400b24c





[MODM-54] New console commands Created: 19/Aug/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: New Feature Priority: Major
Reporter: Jonathan H. Wage Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 0
Labels: None


 Description   

We need to add commands for creating and dropping document databases and collections. I added methods to DocumentManager for creating/dropping databases and collections for documents. We have the command for creating indexes, now we need the same for databases and collections.

The reason is because you can specify configuration for the collection in the mapping that is used on collection creation:

/** @Document(collection={"name"="collname", "capped"="true", "max"="10"}) */
class Document
{}


 Comments   
Comment by Bulat Shakirzyanov [ 23/Aug/10 ]

Jon, these are implemented here http://github.com/doctrine/mongodb-odm/tree/MODM-54, please comment with suggestions, or else I'll merge it in, thanks

Comment by Jonathan H. Wage [ 24/Aug/10 ]

Looks good. Once you implement the changes we discussed via jabber you can merge.

Comment by Bulat Shakirzyanov [ 24/Aug/10 ]

done





[MODM-52] Changes of nested embedded collection are not persisted Created: 18/Aug/10  Updated: 18/Aug/10  Resolved: 18/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: 1.0.0BETA1
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vladimir Razuvaev Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

When there is a nested EmbedMany collection, changes of this collection are not persisted when saving root document.

Maybe simpler to explain with a test case:

/**
 * @MappedSuperClass
 */
class container
{
    /** @String */
    protected $tmp = 'ensureSaved';

    /** @EmbedMany(targetDocument="emb", cascade="all", strategy="set") */
    protected $items = array();

    function __construct($items = null) {if($items) $this->items = $items;}
    function getItems() {return $this->items;}
    function getItem($index) {return $this->items[$index];}
    function removeItem($i) {unset($this->items[$i]);}
}

/** @EmbeddedDocument */
class emb extends container
{}

/** @Document(db="tests", collection="tests") */
class doc extends container
{
    /** @Id */
    protected $id;
}

$emb = new emb(array(new emb(), new emb()));
$doc = new doc(array($emb));

$dm->persist($doc);
$dm->flush();
$dm->refresh($doc);

// change nested embedded collection:
$doc->getItem(0)->removeItem(1);
$before = count($doc->getItem(0)->getItems());

$dm->persist($doc);
$dm->flush();
$dm->refresh($doc);

$after = count($doc->getItem(0)->getItems());
var_dump($before); // outputs 1
var_dump($after);  // outputs 2, but expecting 1


 Comments   
Comment by Vladimir Razuvaev [ 18/Aug/10 ]

I think it might be related to this comment, although not sure.

Comment by Jonathan H. Wage [ 18/Aug/10 ]

Thanks for the issue and test!

Fixed here http://github.com/doctrine/mongodb-odm/commit/3e71c6a6f99360d88c66043ff989d7671e2ded08





[MODM-51] Strange issue with @File annotation Created: 18/Aug/10  Updated: 18/Aug/10  Resolved: 18/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vladimir Razuvaev Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

Not sure if it is ODM issue or some PHP Reflection issue, or I just don't getting something, but following test case won't save the file:

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

    /**
     * @File
     * @var \MongoGridFSFile
     */
    protected $file;

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

$f = new file(__DIR__  . '/test.txt');
$dm->persist($f);
$dm->flush();

The problem is in annotation @var \MongoGridFSFile. Without it file is saved properly. Also, if I remove "\" in front of MongoGridFSFile, file will be also saved properly. Weird thing.



 Comments   
Comment by Jonathan H. Wage [ 18/Aug/10 ]

I think this is a problem with the annotations parser and nothing with the ODM.

Comment by Jonathan H. Wage [ 18/Aug/10 ]

This was an issue with Doctrine Common. I committed a fix for it.





[MODM-29] Persisting changes ordering of elements in embedded collection in some cases Created: 27/Jul/10  Updated: 19/Aug/10  Resolved: 18/Aug/10

Status: Resolved
Project: Doctrine MongoDB ODM
Component/s: Persister
Affects Version/s: 1.0.0ALPHA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Vladimir Razuvaev Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

After changing ordering of elements in collection, it is persisted incorrectly (with different ordering than expected).

Here is a test case:

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

    /** @EmbedMany(targetDocument="emb") */
    protected $collection;

    function __construct($c) {$this->set($c);}

    function set($c) {$this->collection = $c;}
    function get() {return $this->collection;}
}

/** @EmbeddedDocument */
class emb
{
    /** @String */
    protected $val;

    function __construct($val) {$this->val = $val;}
    function get() {return $this->val;}
}

$collection = new ArrayCollection(array(
    new emb('0'),
    new emb('1'),
    new emb('2')
));

// TEST CASE:
$doc = new doc($collection);

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

// place element '0' after '1'
$collection = new ArrayCollection(array(
    $collection[1],
    $collection[0],
    $collection[2]
));

$doc->set($collection);

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

$dm->refresh($doc);

foreach($doc->get() as $value) {
    echo $value->get() . "\n";
}

// expecting: 
// 1
// 0
// 2

// getting: 
// 2
// 1
// 0

Is it an issue? Or is it supposed that ordering should be resolved in application code?



 Comments   
Comment by Jonathan H. Wage [ 27/Jul/10 ]

Hi, I think we should try and make it maintain the order. I will investigate.

Comment by Jonathan H. Wage [ 27/Jul/10 ]

I am not sure if we can control the order. Mongo doesn't give us anyway to do this. We use $pullAll and $pushAll operators currently.

Can you log that test and paste what queries are executed on mongo when persisting?

Comment by Bulat Shakirzyanov [ 27/Jul/10 ]

I think that you should be getting 2,1,0 after the first flush as well, since we would not send an update after the second flush at all. We check whether the actual value in the collection changed or not, if you want the keys to be taken into account, you should use @Hash instead.

Comment by Vladimir Razuvaev [ 28/Jul/10 ]

I have just checked. After first flush I get expected result: 0, 1, 2. And for second flush Doctrine Persister generates following update query:

Array
(
    [$pullAll] => Array
        (
            [collection] => Array
                (
                    [0] => Array
                        (
                            [val] => 0
                        )

                    [1] => Array
                        (
                            [val] => 1
                        )

                )

        )

    [$pushAll] => Array
        (
            [collection] => Array
                (
                    [0] => Array
                        (
                            [val] => 1
                        )

                    [1] => Array
                        (
                            [val] => 0
                        )

                )

        )

)

Then it sequentally executes two updates: 1 for $pullAll and then another for $pushAll (due to http://jira.mongodb.org/browse/SERVER-1050). As a result 1, 0 are pushed after 2 and we get 2,1,0.

I think in many cases using $set would work as a workaround for this issue. But as far as I understand there is no way to hint Doctrine to use $set currently. Or is it possible somehow?

Hash won't work in this case, because it doesn't preserve classes of embedded objects.

Comment by Jonathan H. Wage [ 30/Jul/10 ]

I think we can maybe allow you to force a collection to always use $set if you want to maintain ordering. The downside is it is much slower and not atomic. I don't know if it is a good idea, what do you think?

Comment by Vladimir Razuvaev [ 31/Jul/10 ]

Well, in my use case $set will work well, because embedded objects are small, there will be only 1-40 of them and saving operation is rare. I think this use-case is pretty usual, so $set will be definately useful.

The alternative is to complicate application-code to resolve ordering on the client-side, which doesn't worth it in many cases. And people will use different workarounds as I did: currently I update all embedded objects with unique random token and Doctrine pulls/pushes them all back with valid ordering.

Comment by Jonathan H. Wage [ 07/Aug/10 ]

In this commit http://github.com/doctrine/mongodb-odm/commit/7a9e0088153e1f3f7f9a0650f5f7461bbc41ec64 I made it so that you can control the strategy for persisting. The default value is pushPull but you can also specify set so the entire value is re $set each time:

/** @Collection(strategy="set") */
/** @ReferenceMany(strategy="set") */
/** @EmbedMany(strategy="set") */
Comment by Vladimir Razuvaev [ 17/Aug/10 ]

Discovered another related issue. There are situations with strategy "set", when ODM generates following update query:

array (
  '$set' => array (
    'collection.1.val' => 'tmp',
    'collection' => array (
      0 => array (
        'val' => '1',
      ),
      1 => array (
        'val' => 'tmp',
      ),
      2 => array (
        'val' => '2',
      ),
    ),
  ),
)

E.g. when changing ordering of elements AND field value of any embedded document.
This update will only persist new field value, but not elements reordering.

Full Test Case:

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

    /** @EmbedMany(targetDocument="emb", strategy="set", cascade="all") */
    protected $collection;

    /** @String */
    protected $tmp = ''; // force save

    function __construct($c) {$this->set($c);}

    function getId() {return $this->id;}
    function set($c) {$this->collection = $c;}
    function get() {return $this->collection;}
}

/** @EmbeddedDocument */
class emb
{
    /** @String */
    protected $val;

    function __construct($val) {$this->set($val);}
    function get() {return $this->val;}
    function set($val) {$this->val = $val;}
}

$collection = new ArrayCollection(array(
    new emb('0'),
    new emb('1'),
    new emb('2')
));

// TEST CASE:
$doc = new doc($collection);

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

// place element '0' after '1'
$collection = new ArrayCollection(array(
    $collection[1],
    $collection[0],
    $collection[2]
));

$doc->set($collection);

// changing value together with reordering causes issue when saving:
$collection[1]->set('tmp');

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

$dm->refresh($doc);

foreach($doc->get() as $value) {
    echo $value->get() . "\n";
}

// expecting: 
// 1
// 0
// 2

// getting: 
// 0
// 1
// 2
Comment by Vladimir Razuvaev [ 18/Aug/10 ]

Reopening because of other related issue

Comment by Jonathan H. Wage [ 18/Aug/10 ]

So the "'collection.1.val' => 'tmp'," part succeeds and the rest is ignored? Obviously the 'collection.1.val' => 'tmp', part should not be there.

Comment by Jonathan H. Wage [ 18/Aug/10 ]

Hi, to make things easier would you mind making the test cases in the Doctrine test suite? Every test case you provide is great and it works but I have to spend a few minutes modifying the code and putting it into a test case in phpunit.

Comment by Jonathan H. Wage [ 18/Aug/10 ]

Why are you expecting 1, 0, 2? Wouldn't the change to 'tmp' need to be persisted as well?

Comment by Jonathan H. Wage [ 18/Aug/10 ]

Fixed here http://github.com/doctrine/mongodb-odm/commit/485fbdfb7f85ecb290530ea0fc9c55a6dca91e19

I think the expected values and order would be "1, tmp, 2"

Comment by Vladimir Razuvaev [ 19/Aug/10 ]

Yeah, sorry, expecting "1, tmp, 2" of course.

As for tests - I'll setup Doctrine tests on my side. How should I deliver test cases then? Via github? Or just copy-paste phpunit tests here?





[MODM-20] SINGLE_COLLECTION inheritance does not work Created: 24/Jun/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Closed
Project: Doctrine MongoDB ODM
Component/s: Hydration
Affects Version/s: 1.0.0ALPHA2
Fix Version/s: 1.0.0BETA2

Type: Bug Priority: Major
Reporter: Okapi Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP 5.3.1, Doctrine ODM MongoDB 2010-06-22 16:07:10


Attachments: GZip Archive unit_test.tar.gz    

 Description   

It seems that SINGLE_COLLECTION inheritance is not implemented?

Method UnitOfWork::getOrCreateDocument calls Mapping\Metadata::newInstance without taking possible discriminator map into account.

The example in the official documentation (http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/inheritance-mapping/en) is not a real test: the object is first created as a child-class instance before being queried through the parent class, so the object is returned without hydration, from the UnitOfWork identityMap cache.

The corresponding code from Doctrine\ORM is in Doctrine\ORM\Internal\Hydration\ObjectHydrator::_getEntity (find class name through discriminator map, if any).



 Comments   
Comment by Jonathan H. Wage [ 05/Jul/10 ]

It is just not implemented/finished yet. I will fix the code you mention soon. Thanks, Jon

Comment by Okapi [ 02/Sep/10 ]

Hi Jon,

Indeed, hydration seems aware of the discriminator map now (I only use Single Collection inheritance).

But the discriminator map seems ignored when a document is fetched through its ID (eg. DM::find($class, $id) ).

Because of that, I just can't use this inheritance model. I can't see any possible workaround, since the discriminator field is no longer allowed to be declared in the class.

Other point which is not a bug but a suggestion : instead of using a static discrminator map, couldn't we register an inflector class? Indeed, in most use cases, the document class name is the mere concatenation of the base class with a backslash followed by the camel-cased discriminator value.

Thanks,

Okapi

Comment by Jonathan H. Wage [ 02/Sep/10 ]

Hi, the discriminator map should be used in both DocumentManager::find() and findOne()

http://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/MongoCollection.php#L285
http://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/MongoCollection.php#L315

As far as the inflector class, we have to specify the full discriminator map on the parent class because otherwise we would have to load all the mapping information for all the subclasses to know the information.

Can you give some kind of test code or a test case or something for your reason to re-open?

Comment by Okapi [ 03/Sep/10 ]

Hi, indeed. I've had difficulties in running the PHPUnit tests, but have struggled on the issue within my app long enough to have a clear scenario.

Consider the following unit test:
Doctrine\ODM\MongoDB\Tests\Functional\InheritanceTest::testSingleCollectionInhertiance()

Data has been inserted according to the code before $this->dm->clear();

Now, in a new PHP instance (web req or CLI proc) (to avoid taking any risk related to the reliability of DocumentManager::clear() and make sure objects are freshly hydrated ),

The follow assertion should be OK (I would expect it to be in the test, as it represents the purpose of the discriminator map):
$document = $this->dm->findOne('Documents\Project', array('name' => 'Sub Project'));
$this->assertInstanceOf('Documents\SubProject', $document);

Now, suppose $id is the identifier value of $document as returned by the former code.
The following assertion should be also true:
$document = $this->dm->find('Documents\Project', $id);
$this->assertInstanceOf('Documents\SubProject', $document);

This former test would fail in my case (doc class is Documents\Project as queried).

To me, the purpose of single inheritance is when we don't know by advance the class of the object that hydration will yield. The query is made on a common document class, and the class of each returned document will depend on the discriminator field.
In a typical application, these classes would implement a common interface. Having the possibility to isolate the implementation (concrete class) from the query is a key feature to benefit from the schema-less character of a NoSQL DB.

Am I right, or missing something?

Comment by Jonathan H. Wage [ 03/Sep/10 ]

That is correct, this is how it is intended to work and as far as I've tested it is working that way. I even added your code to the test and it passes: http://github.com/doctrine/mongodb-odm/commit/54f68d9a4623ec7daa18bf5671ebba778bbc0df8

Comment by Okapi [ 06/Sep/10 ]

Hello, after hours of seeking the cause why Doctrine tests pass and mines don't although very similar to each other!!

Answer is: in my project, the base document class which declares the single inheritance behaviour does not include itself in the discriminator map.

Indeed, in the unit tests, Documents\Project is used for both a collection (to query from) and an implementation (of documents with type "project").

In my project, the "collection document class" (setting up the inheritance) is abstract. For now, to please Doctrine ODM, I have included it in the discriminator map under the dumb key "abstract". Doctrine seems fine with it, but there is a logical problem, in the sense that it may try innocently to instanciate my abstract class if it fetches from MongoDB a document with the corresponding type.

What do you think?

Thinking of the case where a fetched document does not match an item in the discriminator map, does the hydrator fall back to the main document class?
Should we have an annotation like @DiscriminatorFallbackValue or @DiscriminatorFallbackDocument ?

If I have suggestions / thinking about how inheritance can be better used, where do you want me to write them? Here or on the forum?

Comment by Jonathan H. Wage [ 06/Sep/10 ]

Can you make a test then with how your entities are setup so I can work on a patch?

Comment by Okapi [ 07/Sep/10 ]

Sorry, I don't have a Github account, and am leaving for a week-long trip, so I don't have th etime yet to make a proper contribution.

However, I have modified tests' Documents\Project, added Documents\OtherSubProject and updated Doctrine\ODM\MongoDB\Tests\Functional\InheritanceTest. Here is a tar.gz of these 3 files.

The instanceOf assertions fails, as the hydrator always returns Documents\Project objects, whatever the "type" is.
Note that adding "project"="Documents\Project" to the discriminator map makes the test pass again.

Comment by Jonathan H. Wage [ 24/Nov/10 ]

I'm pretty certain this is fixed now. I ran your test and it is passing now. I merged the changes and committed it.





Generated at Sun Dec 21 04:10:16 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.