[MODM-180] @DiscriminatorField("type") was not working for me Created: 12/Feb/14  Updated: 10/Apr/14

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

Type: Bug Priority: Major
Reporter: Michael Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Via nginx / mongodb (db version v2.0.4, pdfile version 4.5) I am using symfony2 (2.4.*) with

composer.json:
"php": ">=5.4.0",
"doctrine/mongodb-odm": "1.0.0-BETA9",
"doctrine/mongodb-odm-bundle": "3.0.x-dev",
"doctrine/doctrine-fixtures-bundle": "2.2.*",
"doctrine/data-fixtures": "1.0.*",
"gedmo/doctrine-extensions": "dev-wip-v2.4.0",



 Description   

According to the current documentation http://docs.doctrine-project.org/projects/doctrine-mongodb-odm/en/latest/reference/annotations-reference.html#discriminatorfield it is

 
use Doctrine\ODM\MongoDB\Mapping\Annotations as MongoDB;
/**
 * @MongoDB\Document
 * @MongoDB\InheritanceType("SINGLE_COLLECTION")
 * @MongoDB\DiscriminatorField("type")
 */
class SuperUser
{
    // ...
}

and I got the following exception

 
[MongoException] zero-length keys are not allowed, did you use $ with double quotes?

which was hard to track down in the first place, as there is no useful stack trace showed. What was working for me was:

 
use Doctrine\ODM\MongoDB\Mapping\Annotations as MongoDB;
/**
 * @MongoDB\Document
 * @MongoDB\InheritanceType("SINGLE_COLLECTION")
 * @MongoDB\DiscriminatorField(fieldName="type")
 */
class SuperUser
{
    // ...
}


 Comments   
Comment by Jeremy Mikola [ 10/Apr/14 ]

This was actually changed in https://github.com/doctrine/mongodb-odm/commit/ebb7d5fe826f448fc4a53203c23bcc85e610b858. The documentation from that change is what is currently published, but the code is still sitting in the master branch since there's no 1.0.0-BETA10 tag yet.

Your work-around is valid, and will continue to work with 1.0.0-BETA10, since I've left BC support for the old annotation style. My apologies for the inconvenience.





[MODM-176] includesReferenceTo query failure Created: 09/Nov/13  Updated: 20/Jan/14

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

Type: Bug Priority: Minor
Reporter: Hussain Nazan Naeem Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: dql
Environment:

MongoDB shell version: 2.4.6



 Description   

Problem explained below as an example.
Suppose Car model has referenceMany relation with Wheel model.

/** @ReferenceMany(targetDocument="Wheel", inversedBy="car", simple=true) */
protected $wheels

note the simple=true param. If this param is specified then includesReferenceTo queries fail for Car model.

For example, following query fails:

$cars = $dm->createQueryBuilder('Car')
            ->field('wheels')
            ->includesReferenceTo($wheel)
            ->getQuery()
            ->execute();





[MODM-179] Wrong LifecycleCallbacks type object passed Created: 16/Jan/14  Updated: 16/Jan/14

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

Type: Bug Priority: Critical
Reporter: Pierre B Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.4.24
Symfony 2.4



 Description   

I've an exception error when trying to update an object, due to the lifecycle callback:

Expected document class "Ae\CoreBundle\Document\Advertiser"; found: "MongoDBODMProxies_CG_\Ae\CoreBundle\Document\Advertiser"

The stack trace says it comes from:
ClassMetadataInfo ->invokeLifecycleCallbacks ('preUpdate', object(Advertiser))

I have to disable my lifecycle callbacks to keep my app working... wich is really bad.

Thank you for your help,

Best regards






[MODM-178] Add an event that allows adjustment of a query prior to being executed Created: 03/Jan/14  Updated: 03/Jan/14

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Query Builder
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Westin Pigott Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I would like to add an event which is triggered upon the creation of a query, and prior to the query being executed. This would allow the query to be modified prior to execution.

This would be useful in the following use case (off the top of my head):

  1. A developer needs to set the scope of a query. An example would be: In a white-label site situation where you want to make sure the login only checks for the correct user in the scope of the domain. Rather than needing to make sure that every query has the scope added when the query is defined, the scope could be added prior to execution.
  2. Users want to enable encryption on certain fields. The encrypting and decrypting part are fairly straight-forward using the existing events. The problem is encountered when you have to be aware of the encryption when composing a query. If we could modify the query prior to execution, we could check the fields and adjust the search values as needed.


 Comments   
Comment by Westin Pigott [ 03/Jan/14 ]

BTW, if you point me in the general direction, I would be happy to do the work on this issue.





[MODM-177] mapping import with multiple schema Created: 02/Dec/13  Updated: 02/Dec/13

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alexandre PIEL Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I am importing the structure of my database by using doctrine:mapping:import
When I run doctrine:generate:entities I get the error: Invalid mapping file

The exception come from the following code in the function getElement l.105 if the class Doctrine\Common\Persistence\Mapping\Driver\FileDriver

if (!isset($result[$className]))

{ throw MappingException::invalidMappingFile($className, str_replace('\\', '.', $className) . $this->locator->getFileExtension()); }

When I look more in details we have

$clasName = "Company\Eg\Entity\Schema\table"

And $result is:

array(1) {
["Company\Eg\Entity\Schema.table"]=>
array(5) {
(...)

I am using PostgreSQL with multiple schemas for a single database.






[MODM-175] Removing file data from Document with file removes other fields aswell Created: 26/Aug/13  Updated: 02/Sep/13

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Document Manager
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Peter Jasiulewicz Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony2, Doctrine ODM bundle



 Description   

Not sure if this project isn't abandoned as it looks but here goes.

There is a problem with the gridfs files deletion.
going by description in https://doctrine-mongodb-odm.readthedocs.org/en/latest/reference/storing-files-with-mongogridfs.html?highlight=file

I created a document, the problem is, most of the times, the file is just temporary in mongodb (in my app anyway), and gets deleted after. The deletion (or $document->setFile(null) ) on the @MongoDB\File also removes all other fields in that document, besides the data itself. I have a bunch of statistical information in that document, and it all gets removed when I just remove the file. What's left is just the Id. This might be the way it was intended, however doesn't not really seam like the mapping is accurate here, as it obviously removes a lot more from the database, than I from the object.

The operation should just remove the data that has been removed from the object.



 Comments   
Comment by Jonathan H. Wage [ 02/Sep/13 ]

This project has been a bit more active on github.com/doctrine/mongodb-odm

Comment by Peter Jasiulewicz [ 02/Sep/13 ]

Should I repost it then?

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

Yes, I think it would help with other devs/users seeing it.

Comment by Peter Jasiulewicz [ 02/Sep/13 ]

OK, guess this can be closed then as a duplicate. Thanks.

https://github.com/doctrine/mongodb-odm/issues/668





[MODM-174] Referenced document not removed Created: 19/Jul/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

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

Type: Bug Priority: Major
Reporter: Robert Dolca Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None


 Description   

I am using something like this http://docs.doctrine-project.org/projects/doctrine-mongodb-odm/en/latest/reference/storing-files-with-mongogridfs.html

Let`s say I get a profile from DB and I do:

$image = $profile->getImage();
$profile->setImage(null);
$dm->remove($image);
$dm->flush();

the image is not deleted/removed from DB. When I do this:

$image = $dm->getRepository('Image')>findOneById($profile>getImage()->getId());
$profile->setImage(null);
$dm->remove($image);
$dm->flush();

the image is removed.



 Comments   
Comment by Robert Dolca [ 19/Jul/13 ]

Annotation error. My bad





[MODM-173] Change the name of the collection dynamic Created: 27/Jun/13  Updated: 27/Jun/13

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

Type: Improvement Priority: Minor
Reporter: Daniel Gafitescu Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have to create collection for users per each day they register so if I have 5 users and 2 register on 2013-03-02 and 3 have register on 2013-03-03 I will have 2 collections

The user is declare in a YML file with no collection specified

In the project I do an import via CLI something like this

foreach($arUsers as $key => $arUser)
{

    $collection_name = 'day_' . $arUser['date'];


    $user = new User();

    /* Change the collection name to be dynamic  */
    $OdmMetaData = $documentManager->getClassMetaData(get_class($user));

    $OdmMetaData->setCollection($collection_name);

    $user->setUserId($arUser['user_id']);
    $user->setEmail($arUser['email']);

    // ....

    $this->getDocumentManager()->persist($user);
    $this->getDocumentManager()->flush();
    
    // should save the user to `'day_' . $arUser['date']`
}

Problem is that when I look in the mongoDB I see only one collection with name "day_2013-03-03" which is the last date , if I set the

$documentManager->flush();

after the foreach end statement which I should it save all in the first collection "03-02".



 Comments   
Comment by Marco Pivetta [ 27/Jun/13 ]

I personally don't think that's an use case to be handled in the ODM.

The problem is that class metadata properties are not constantly accessed, but instead cached locally in various components for performance reasons.

A fix for this would be to explicitly deny modification of metadata after it was returned by the metadata factory (after "onLoadMetadata" events).

Comment by Daniel Gafitescu [ 27/Jun/13 ]

Reinitialize the DoctrineManager at every group of document did the trick but it's just not beautiful code.
In a perfect world it would be nice to have a method setCollectionName on a object. But then again Doctrine is a open source project and all that work on the project are doing this on their own time and I thank you for that.





[MODM-172] Fulltextsearch available in Mongo 2.4 is not available in MongoODM Created: 04/Jun/13  Updated: 04/Jun/13

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

Type: Bug Priority: Major
Reporter: Jean-Tristan Chanegue Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mongo 2.4 / MacosX / PHP 5.3.14



 Description   

Since Mongo 2.4, Fulltextsearch is available: http://docs.mongodb.org/manual/core/text-search/
It's possible to use it directly in PHP :

Command of Mongo 2.4 Text Search feature.

<?php
$result = $db->command(
array(
'text' => 'bar', //this is the name of the collection where we are searching
'search' => 'hotel', //the string to search
'limit' => 5, //the number of results, by default is 1000
'project' => Array( //the fields to retrieve from db
'title' => 1
)
)
);

Sadly it's not available (or i did not find a way..) to use this great feature of Mongo in MongoODM.






[MODM-171] Calling ->toArray on a Cursor causes CLI script called by exec to do a void return (only on exec/shell_exec call) Created: 28/May/13  Updated: 28/May/13  Resolved: 28/May/13

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

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

ODM version : 1.0.0-BETA8 - Linux - Debian - PHP 5.4



 Description   

All is here : http://stackoverflow.com/questions/16786763/doctrine-odm-calling-toarray-on-a-cursor-causes-cli-script-called-by-exec-to-d



 Comments   
Comment by souf [ 28/May/13 ]

Was a problem on the permissions, but only with doctrine. Solved temporary by setting Unix user permissions to 777 on the application folder





[MODM-170] Unique index on embedded document Created: 15/May/13  Updated: 15/May/13

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

Type: Bug Priority: Major
Reporter: Szymon Karnecki Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi,

Bug checked on versions:
doctrine/mongodb-odm (1.0.0-BETA7)
doctrine/mongodb-odm-bundle (v3.0.0-BETA3)
and
doctrine/mongodb-odm (dev-master 6fd7a46)
doctrine/mongodb-odm-bundle (dev-master 23c08a4)

I've created unique index on embedded document and ODM seem not to be working properly. When unique index is violated MongoCursorException is thrown and this behavior is desired.
But, the document sometimes is persisted anyway. Document structure is invalid.

Thrown exception:
mymongoserver.xx:27017: E11000 duplicate key error index: prj.Grid.$boxes_offer_$id_1_boxes_tag_$id_1 dup key: { : ObjectId('51555bbe31bcb2c70e000001'), : "dom" }

Grid document sketch:

{ _id: boxes:[DBref(Offer), DBref(Offer), DBref(Offer)] tag: DBref(Tag) }

unique index on boxes.tag

Any help would be appreciated.






[MODM-169] Filter API is not unified between ODM and ORM Created: 10/Dec/12  Updated: 10/Dec/12

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Document Manager
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Craig Marvelley Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Hi,

I'm implementing some functionality around filters which will ideally work for both ORM and ODM. The API for managing filters is different on `Doctrine\ORM\EntityManager` and `Doctrine\ODM\MongoDB\DocumentManager`, while the CouchDB implementation of ODM has no filter concept.

For example, ORM EntityManager has getFilters(), hasFilters(), while ODM MongoDB DocumentManager has getFilterCollection().

I was wondering what your thoughts were on defining the filter API in an interface, to improve consistency when implementing cross-library functionality?

Thanks,
Craig






[MODM-168] Can't Use Custom Repository Class for Embedded Doc When Using YAML Driver Created: 29/Jul/12  Updated: 29/Jul/12

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Isaac Foster Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using the Yaml driver the ClassMetadata generation process won't create and use the indicated custom repository class for an embedded document. From what I can see digging into the actual code, it will work when using the Annotations or XML drivers, but in the Yaml driver the call to setCustomRepositoryClass is inside of a conditional that only gets entered if the document type is 'document'.

I'm not completely sure, but from what I can see elsewhere in the code, it looks like mapped superclasses should also be able to have a custom repository class, but can't when using the Yaml driver.

So I reckon what would work would be to change the code as indicated below:

<<EXISTING CODE>>
//Doctrine/ODM/MongoDb/Mapping/Driver/YamlDriver.php, line 66
if ($element['type'] == 'document') {
if (isset($element['repositoryClass']))

{ $class->setCustomRepositoryClass($element['repositoryClass']); }

} elseif ($element['type'] === 'mappedSuperclass')

{ $class->isMappedSuperclass = true; }

elseif ($element['type'] === 'embeddedDocument')

{ $class->isEmbeddedDocument = true; }

<<TO THIS>>
if (isset($documentAnnot->repositoryClass))

{ $class->setCustomRepositoryClass($element['repositoryClass']); }




[MODM-166] recomputeSingleDocumentChangeSet does not work for collections Created: 24/Jun/12  Updated: 27/Jun/12  Resolved: 27/Jun/12

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

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


 Description   

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

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



 Comments   
Comment by Tim Roediger [ 26/Jun/12 ]

PR open with fix https://github.com/doctrine/mongodb-odm/pull/336

Comment by Tim Roediger [ 27/Jun/12 ]

PR merged





[MODM-167] Undefined index exception when a new document is detatched in onFlush Created: 26/Jun/12  Updated: 27/Jun/12  Resolved: 27/Jun/12

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

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


 Description   

Test and fix PR to come shortly



 Comments   
Comment by Tim Roediger [ 27/Jun/12 ]

Commit a260002 merged to resolve issue.





[MODM-161] Bug with index definition Created: 06/Feb/12  Updated: 15/Jun/12

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Erwann Mest Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MacOS 10.7.2



 Description   

All is there: https://gist.github.com/1682981



 Comments   
Comment by Luis Cordova [ 15/Jun/12 ]

github link has nothing it was removed

Comment by Luis Cordova [ 15/Jun/12 ]

gist is a broken link





[MODM-165] Identity map doesn't work (tested only with Symfony) Created: 20/Apr/12  Updated: 20/Apr/12  Resolved: 20/Apr/12

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

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

mongodb version 2.0.2, mac os x lion, Symfony master



 Description   

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

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



 Comments   
Comment by Ludovic [ 20/Apr/12 ]

I misunderstood the identity map usage, actually I discover in the code that it was strictly restricted to find() method and the load method didn't fetch from the identityMap (even if the query carry only an id criteria). I'm not sure of all impact, but I think it could be quite easy to fix this. I'll try to open an issue and maybe to PR. Thanks.





[MODM-149] Fix PHPDoc @return types in various places Created: 05/Jul/11  Updated: 05/Apr/12

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

Type: Documentation Priority: Critical
Reporter: Dayson Pais Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In certain PHPDoc blocks for functions, the @return type is not of the right type. This causes auto-completion issues in various IDEs (I'm using PhpStorm).

For example, in \Doctrine\ODM\MongoDB\DocumentManager on line #341 the ->createQueryBuilder($documentName = null) function.

/**

  • Create a new Query instance for a class.
    *
  • @param string $documentName The document class name.
  • @return Document\ODM\MongoDB\Query <--------------------------- MUST BE Query\Builder !
    */
    public function createQueryBuilder($documentName = null) { return new Query\Builder($this, $this->cmd, $documentName); }


 Comments   
Comment by Lee Davis [ 05/Apr/12 ]

This appears to be fixed in 1.0.0BETA4-DEV

Line 357 in Doctrine\ODM\MongoDB\DocumentManager...

/**

  • Create a new Query instance for a class.
    *
  • @param string $documentName The document class name.
  • @return Query\Builder
    */
    public function createQueryBuilder($documentName = null) { return new Query\Builder($this, $this->cmd, $documentName); }




[MODM-164] DocumentPersister's prepareQuery() method is not suitable for preparing newObj for update queries Created: 05/Apr/12  Updated: 05/Apr/12

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

Type: Bug Priority: Major
Reporter: Juha Suni Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Doctrine\ODM\MongoDB\Query\Expr::getNewObj() uses Doctrine\ODM\MongoDB\Persisters\DocumentPersister::prepareQuery() method for preparing newObj. However, prepareQuery is not suitable for that.

The first lines in prepareQuery method should apply to find queries only:


if (is_scalar($query) || $query instanceof \MongoId) {
$query = array('_id' => $query);
}
if ($this->class->hasDiscriminator() && ! isset($query[$this->class->discriminatorField['name']])) {
$discriminatorValues = $this->getClassDiscriminatorValues($this->class);
$query[$this->class->discriminatorField['name']] = array('$in' => $discriminatorValues);
}


Recommendation: DocumentPersister should introduce a new method, such as prepareNewObj($newObj) for preparing the newObj array. Expr::getNewObj() should be change to invoke the new method.






[MODM-163] @ReferenceMany and Inheritance Created: 01/Mar/12  Updated: 01/Mar/12

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

Type: Bug Priority: Minor
Reporter: julie sommerville Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

php 5.3 macosx 10.7.3 mongodb-odm 1.0 mongodb v2.0.2



 Description   

@ReferenceMany doesn't seem to work when used within a child class unless I specify @InheritanceType("CLASS_PER_COLLECTION") (which is fine b/c that works for our architecture)

Here is an example from our code:

//Parent Class

use Doctrine\Common\Collections\ArrayCollection;

/**

  • @Document(collection="homepages")
  • @ChangeTrackingPolicy("DEFERRED_IMPLICIT")
  • @Indexes({
  • @Index(keys= {"vertical"="asc","ts"="desc"}

    , safe="true"),

  • @Index(keys= {"ts"="desc"}

    , safe="true")

  • })
    */
    class Homepage extends MappedDocument
    {

//** References
/**

  • @ReferenceMany(targetDocument="Post")
  • @var list<Post>
    */
    protected $touts;

}

//Child Class
/**

  • @Document(collection="readmes")
  • @ChangeTrackingPolicy("DEFERRED_IMPLICIT")
  • @Indexes({
  • @Index(keys= {"vertical"="asc"}

    , safe="true")

  • })
    */
    class Readme extends Homepage { //** References /** * @ReferenceMany(targetDocument="Post") * @var list<Post> */ protected $more_touts; }

If I don't add the @InheritanceType annotation the $more_touts data never gets persisted into the DB.
Other types such as @ReferenceOne all work just fine






[MODM-153] "Near" Query does not work. Created: 10/Aug/11  Updated: 20/Feb/12

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

Type: Bug Priority: Critical
Reporter: Dmitry Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

"Near" statement does not work for me. The following code returns all cities from collection:

$cities = $this->dm->createQuery('City')
    ->field('coordinates')->near(50, 60)
    ->execute();

Could you please fix it?



 Comments   
Comment by mark wright [ 02/Sep/11 ]

It also does not work in beta3 but it fails differently. It never returns anything.

$places = $documentManager->createQueryBuilder('Documents\Place')
->field('point')
->near(36.5788494, -121.7207804)
->getQuery()
->execute();

This returns 0 documents even though I have a point at 36.5788493, -121.7207805. Doctrine\MongoDB\Query\Builder::near() only takes one argument so the Y value is ignored. However, the docblock specifies 2 params.

Comment by Tim Sakharchuk [ 04/Sep/11 ]

Hi All,

Here is correct realization of this function in
Doctrine\MongoDB\Query\Builder

public function near($x, $y)

{ $this->query['type'] = Query::TYPE_GEO_LOCATION; $this->query['near'] = array($x, $y); return $this; }

When may this fix appear in Doctrine ODM?

Thanks!

Comment by Shane A. Stillwell [ 20/Feb/12 ]

I had the same issue on 1.0.0.BETA3.

The solution was to change the query up a little.

$places = $this->dm->createQueryBuilder('\Application\Event')->field('latitude')->near(50)->field('longitude')->near(60)->getQuery()->execute(); 

http://stackoverflow.com/a/9015906/179335





[MODM-162] Introduction Tutorial,suitable version Created: 15/Feb/12  Updated: 15/Feb/12

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

Type: Documentation Priority: Major
Reporter: Hugues Leunsa Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

software



 Description   

HI all,

I am working on a project where I would like to use mongoDB ODM. But while following this tutotorial : http://docs.doctrine-project.org/projects/doctrine-mongodb-odm/en/latest/reference/introduction.html, it appears to me that the download odm library doesn't work with the code: missing code or undefined classes. Therefore I woulld like to know what's the corresponding version mongodb ODM of the tutorial.

Thank's in advance

regards

near






[MODM-160] Errors when merging new documents with two levels of embedded documents Created: 11/Jan/12  Updated: 04/Feb/12  Resolved: 04/Feb/12

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

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

Mac OS X 10.7, All code is the latest version of master.



 Description   

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

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

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

Otherwise it's:

Undefined index: <blank>

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



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

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





[MODM-140] Issue with nested embdedded documents after adding an EmbeddedDocument to Document Created: 14/Apr/11  Updated: 19/Dec/11

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

Type: Bug Priority: Major
Reporter: Andrew Cobby Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 5
Labels: None
Environment:

PHP 5.3.3, Mac OS X 10.6.6, MongoDB 1.8.0


Attachments: File doctrine-odm-patch-1.0.0beta3.diff     File MODM140Test.php    

 Description   

I'm using the latest version of Doctrine ODM (fresh from Git).

I have three levels of Documents (Two embedded); Category -> EmbedsMany: Post -> EmbedsMany PostVersion.

Step-by-step:

1. Make a new Post (Post1), 2 PostVersions (PostVersion1 and 2) and a Category
2. Add Post1 to Category
3. Persist Category, Flush, Clear
4. Retrieve Category
5. Make a new Post (Post2) and 2 PostVersions(PostVersion3 and 4)
6. Add Post2 to Category
7. Flush

If you're following properly, at this stage in the database there should be:
1 Category,
2 Posts
4 PostVersions ... 2 PostVersions in each Post

However, what actually happens is:
1 Category,
2 Posts
4 PostVersions ... 4 PostVersions in Post1, 0 PostVersions in Post2

On StackOverflow: http://bit.ly/ekFbe2
Testcase Gist: https://gist.github.com/920914

A work around is to make Post2 and add it to Category, flush, then make new PostVersions and flush again.

I did some debugging but I don't know enough about the internals to fix the issue.



 Comments   
Comment by Andrew Cobby [ 14/Apr/11 ]

Failing test

Comment by Andrew Cobby [ 14/Apr/11 ]

Added a test using the EmbdeddedTestLevelX Documents, please refer to Gist: https://gist.github.com/920914

For some reason, they work? I'm thinking maybe this isn't a bug... very confused at the moment.

Comment by Andras Revai [ 18/Jun/11 ]

I've got the same problem.

Comment by Kelvin Wood [ 09/Aug/11 ]

I had a similar problem, and resolved it with the attached patch (based on the 1.0.0beta3 release).

This patch causes the ODM to stop scanning for changes further down the heirachy once it finds a new object, and then ensures that the Persistence Builder will include all contents of the new item.

Comment by Richard Shank [ 19/Dec/11 ]

Kevin, do you want to put a PR in on github for this?





[MODM-159] Querying a collection by Embedded objects identifier not working. Created: 30/Nov/11  Updated: 30/Nov/11

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

Type: Bug Priority: Major
Reporter: Dahuda Unal Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OS:10.8.0 OSX
PHP Official Version 5.3.8
MongoDB : 2.0.1



 Description   

Reference objects identifiers are stored as '$id' in database when Embedded objects identifiers are stored as '_id'. When querying a collection by embedded objects identifier, DocumentPersister->prepareQueryValue() converts it to '$id' although it is stored in DB as '_id'. So querying for reference object ids work but embedded objects do not.

DocumentPersister->prepareQueryValue() first checks if field has TargetDocument mapping, if it is true it checks if field is target document's identifier, if this also returns true
it prepares the field as '$id' without looking at if it is Embedded or Reference object ... If TargetDocument it is a Reference object it works since Reference objects identifiers are stored as '$id' but if TargetDocument is Embedded object, query returns empty as theres no field such '$id' in EmbeddedObject, identifier is '_id' instead..

Is this a bug / issue or am i missing something?






[MODM-158] Doctrine\ODM\MongoDB\Mapping\Type\TimestampType should use MongoDate instead of MongoTimestamp Created: 24/Nov/11  Updated: 24/Nov/11

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

Type: Bug Priority: Major
Reporter: Shane A. Stillwell Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OS 10.7

PHP 5.3.6 with Suhosin-Patch (cli) (built: Sep 8 2011 19:34:00)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with Xdebug v2.1.2, Copyright (c) 2002-2011, by Derick Rethans


Attachments: Text File mongodate.patch    

 Description   

When using the @Timestamp mapping type for a class Doctrine uses MongoTimestamp and it creates very incorrect times in the DB. According to PHP documentation, you should not use MongoTimestamp for creating timestamps, instead MongoDate should be used.

I've attached a patch that changes it to MongoDate and this works splendid when you assign a timestamp to a @Timestamp value

	/**
	 * @Field(type="timestamp")
	 */
	protected $created_on;

	/**
	 * @Field(type="timestamp")
	 */
	protected $updated_on;

	public function __construct($options = NULL)
	{
		$this->created_on = $this->updated_on = time();
		parent::__construct($options);
	}





[MODM-145] QueryBuilder references() to does not support references on embedded objects' fields Created: 23/May/11  Updated: 25/Oct/11

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Query Builder
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Jeremy Mikola Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I noticed that the references() method does not support fields on embedded objects, as the argument to the preceding field() method will be passed into getFieldMapping() and trigger an exception. I suppose a solution would require multiple calls to getFieldMapping() in order to dive into the embedded object's class metadata.

To demonstrate, below is an example of a UserRepository class. The User document contains an embeddedObject that itself references another User:

class UserRepository extends DocumentRepository
{ 
    public function findByEmbeddedObjectReference(User $user)
    {
        return $this->createQueryBuilder()
            ->field('embeddedObject.user.$id')->equals($user->getId())
//          ->field('embeddedObject.user')->references($user)
            ->getQuery()
            ->execute();
    }
}

Using field()/equals() works fine as an alternative to references(), so there is no urgent need for this feature.



 Comments   
Comment by Nicolas Brignol [ 25/Oct/11 ]

Hi

It seems that we have a problem with the temporary solution proposed :
Doctrine remove the "$id" part in our query :

   obj->field('embedded.referenced.$id')->equals($reference->getId())

will generate the query without "$id".
There is no problem when the reference is directly in the requested object.

Did someone experience this issue ?





[MODM-157] Github-PR-151 by l3pp4rd: fixes triggering fatal error on preupdate event in case changeset is clea Created: 25/Aug/11  Updated: 19/Sep/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of

{username}

:

Url: https://github.com/doctrine/mongodb-odm/pull/151

Message:

fixes triggering fatal error on preupdate event in case changeset is cleared during onFlush

similar issue is fixed in ORM it should be supported on ODM mongodb also



 Comments   
Comment by Dmitry Strygin [ 19/Sep/11 ]

Hmm... The bug is still actual for ORM layer in master.

Comment by Vladimir Garvardt [ 19/Sep/11 ]

Got the same issue for ORM in 2.1.1 and same in master. Made a fix based on fix for ODM and pull request on github.

URL: https://github.com/doctrine/doctrine2/pull/126

PS: maybe new issue should be created in Doctrine 2 - ORM project for this issue





[MODM-156] Github-PR-152 by vladar: Property ClassMetadata::file is not serialized Created: 25/Aug/11  Updated: 25/Aug/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of

{username}

:

Url: https://github.com/doctrine/mongodb-odm/pull/152

Message:

This is causing errors, when saving gridfs files with persistent metadata cache engine (like apc, memcached, etc).

I've also found same bug in Jira - http://www.doctrine-project.org/jira/browse/MODM-132 but seems that it is not fixed yet.

Added fix + tests.






[MODM-155] Github-PR-148 by roed: fixed generating of classes Created: 21/Aug/11  Updated: 21/Aug/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of

{username}

:

Url: https://github.com/doctrine/mongodb-odm/pull/148

Message:

fixed the generating of classes based on xml files, changed ClassMetadata to ClassMetadataInfo in these files (as in the ORM tool/mapping)

the following did not work, but works after these changes:
$cmf = new \Doctrine\ODM\MongoDB\Tools\DisconnectedClassMetadataFactory();
$cmf->setDocumentManager($this->_dm);
$cmf->setConfiguration($this->_dm->getConfiguration());
$driver = $this->_dm->getConfiguration()->getMetadataDriverImpl();

$metadatas = $cmf->getAllMetadata(); //this would break it

// $this->_dm is an instance of Doctrine\ODM\MongoDB\DocumentManager






[MODM-154] Github-PR-150 by tecbot: [XMLDriver] fixed an error in hydration classes when the name is not equal to the fieldName Created: 21/Aug/11  Updated: 21/Aug/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of

{username}

:

Url: https://github.com/doctrine/mongodb-odm/pull/150

Message:






[MODM-152] Single Collection Inheritance mapping does NOT work if the subclasses are in a different namespace Created: 09/Jul/11  Updated: 09/Jul/11

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

Type: Bug Priority: Major
Reporter: Dayson Pais Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have described the issue in detail here: https://github.com/doctrine/mongodb-odm/issues/124






[MODM-151] Missing Annotation class HasLifecycleCallbacks Created: 07/Jul/11  Updated: 07/Jul/11

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

latest MongoDB ODM from git master repository



 Description   

Annotation class HasLifecycleCallbacks is missing in Doctrine\ODM\MongoDB\Mapping\Annotations






[MODM-150] XSD file for XML mappings is incomplete Created: 07/Jul/11  Updated: 07/Jul/11

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

Type: Bug Priority: Major
Reporter: alcaeus Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File doctrine-mongo-mapping.xsd.patch    

 Description   

The XSD file for XML mappings (http://www.doctrine-project.org/schemas/odm/doctrine-mongo-mapping.xsd) appears to be incomplete:

  • Only document is allowed as root tag, not mapped-superclass or embedded-document
  • The name attribute for the document tag is not allowed according to the XSD file
  • The fieldName, index and unique attributes for the field tag is not allowed according to the XSD file

These are the problems I discovered at the moment, I haven't yet checked for more problems. The XSD file probably needs a bigger update.

Attached is a patch file that adds the missing attributes, I haven't dug into Doctrine enough to create the mapped-superclass or embedded-document tags.






[MODM-148] Do not add '$db' in reference when referencing document from same $db Created: 02/Jun/11  Updated: 02/Jun/11

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Document Manager
Affects Version/s: None
Fix Version/s: None

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


 Description   

When using ReferenceOne or ReferenceMany , doctrine will create fully-qualified reference to the object (with all fields: '$id', '$ref', '$db') even when reference is within same $db.

This approach causes several problems: for example we use mongo database as a template for new clients - when new client registers, template database is copied for him. But since it contains hardcoded $db - copy operation becomes resource consuming, since we have to loop through every document of every collection and fix $db reference.

Also maintenance suffers, since you can't easily rename database when required.

Is it possible to omit $db part when referencing document from same db?






[MODM-147] No possibility to get a json object by a working document with toArray method (inluding all the embedded documents as arrays) Created: 28/May/11  Updated: 28/May/11

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

Type: New Feature Priority: Major
Reporter: Stephan Salat Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Irrelevant



 Description   

Description of the problem here:

http://stackoverflow.com/questions/6155189/doctrine-odm-mongodb-get-a-complete-array-of-an-object

Problem with the unincisive toArray() method.






[MODM-146] Doctrine MongoDB ODM load referenced documents ends in an endless loop Created: 24/May/11  Updated: 28/May/11  Resolved: 28/May/11

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

Type: Bug Priority: Major
Reporter: Stephan Salat Assignee: Jonathan H. Wage
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

PHP Zend Framework on Ubuntu 10.10



 Description   

Description of the problem here:

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



 Comments   
Comment by Stephan Salat [ 28/May/11 ]

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





[MODM-144] Bi-Directional References Feature Created: 18/May/11  Updated: 18/May/11

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

Type: Bug Priority: Minor
Reporter: Jan Gantzert Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Zend Framework 1.11.6



 Description   

I cant´t reproduce the Bi-Directional References with my own example or the example of the documentation.
Perhaps the documentation is not up to date or their ist a bug.

BlogPost.php
<?php

/** @Document */
class BlogPost
{
/** @Id */
public $id;

/** @String */
public $title;

/** @String */
public $content;

/** @String */
public $createtime;

/** @String */
public $updatetime;

/** @ReferenceMany(targetDocument="PostComment", mappedBy="post") */
private $comments;
}

PostComment.php
<?php

/** @Document */
class PostComment
{
/** @Id */
public $id;

/** @String */
public $name;

/** @String */
public $mail;

/** @String */
public $content;

/** @String */
public $createtime;

/** @String */
public $updatetime;

/** @ReferenceOne(targetDocument="BlogPost", inversedBy="comments") */
private $post;
}

CommentController.php
// Save the Post
$post = new BlogPost();
$post->setTitle = 'testtitle';
//$post->content = 'testcontent';
//$post->createdate = time();

$comment1 = new PostComment();
$comment1->title = 'testcommenttitle1';

$comment2 = new PostComment();
$comment2->title = 'testcommenttitle2';

$comment3 = new PostComment();
$comment3->title = 'testcommenttitle3';

$dm->persist($comment1);
$dm->persist($comment2);
$dm->persist($comment3);
$dm->flush();

echo $post->id;

/*$posts = $dm->createQueryBuilder('BlogPost')
->getQuery();*/

$post = $dm->getRepository('BlogPost')->find('4dd45739f563724c23000002');

Zend_Debug::dump($post);
$comments = $post->getComments();

------------------------
In the documentation the example is
$post1->setUser($user);
But the only working for me is:
$post->setTitle = 'testtitle';

Anyway, I can´t get the Comments from the mongodb.
I always get this error.
Fatal error: Call to undefined method BlogPost::getComments()
This is a correct error message because BlogPost really dont have a getComments()
method. How do I get my Comments then?
Any help would be great.

Greetings tronga






[MODM-143] Mismatch in configuration classes, can't enable logging Created: 11/May/11  Updated: 16/May/11  Resolved: 16/May/11

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

Type: Bug Priority: Trivial
Reporter: Stanislav Korchagin Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

My bootstrap:

 
        $config = new Doctrine\ODM\MongoDB\Configuration();
        $config->setProxyDir(APPLICATION_PATH . '/../data/cache');
        $config->setProxyNamespace('Proxies');
        $config->setDefaultDB([skip]);

        $config->setHydratorDir(APPLICATION_PATH . '/../data/cache');
        $config->setHydratorNamespace('Hydrators');

        $config->setLoggerCallable(function(array $log) { print_r($log); });

        $reader = new \Doctrine\Common\Annotations\AnnotationReader();
        $reader->setDefaultAnnotationNamespace('Doctrine\ODM\MongoDB\Mapping\\');
        $config->setMetadataDriverImpl(
            new \Doctrine\ODM\MongoDB\Mapping\Driver\AnnotationDriver($reader, __DIR__ . '/Documents')
        );

        $manager = \Doctrine\ODM\MongoDB\DocumentManager::create(
            new \Doctrine\MongoDB\Connection(),
            $config
        );

And nothing happens

Trace from Doctrine\MongoDB\Configuration::getLoggerCallable():

#0 [skip]/Doctrine/MongoDB/Connection.php(248): Doctrine\MongoDB\Configuration->getLoggerCallable()
#1 [skip]/Doctrine/MongoDB/Connection.php(231): Doctrine\MongoDB\Connection->wrapDatabase(Object(MongoDB))
#2 [skip]/Doctrine/ODM/MongoDB/DocumentManager.php(287): Doctrine\MongoDB\Connection->selectDatabase([skip])
#3 [skip]/Doctrine/ODM/MongoDB/DocumentManager.php(316): Doctrine\ODM\MongoDB\DocumentManager->getDocumentDatabase('BPM\User')
#4 [skip]/Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php(148): Doctrine\ODM\MongoDB\DocumentManager->getDocumentCollection('BPM\User')
#5 [skip]/Doctrine/ODM/MongoDB/UnitOfWork.php(319): Doctrine\ODM\MongoDB\Persisters\DocumentPersister->__construct(Object(Doctrine\ODM\MongoDB\Persisters\PersistenceBuilder), Object(Doctrine\ODM\MongoDB\DocumentManager), Object(Doctrine\Common\EventManager), Object(Doctrine\ODM\MongoDB\UnitOfWork), Object(Doctrine\ODM\MongoDB\Hydrator\HydratorFactory), Object(Doctrine\ODM\MongoDB\Mapping\ClassMetadata), '$')
#6 [skip]/Doctrine/ODM/MongoDB/DocumentRepository.php(115): Doctrine\ODM\MongoDB\UnitOfWork->getDocumentPersister('BPM\User')
#7 [skip]application/library/BPM/UserData.php(43): Doctrine\ODM\MongoDB\DocumentRepository->find('4dc9d0192d91365...')
[skip]

get_class($this) from Doctrine\MongoDB\Configuration::setLoggerCallable() write 'Doctrine\ODM\MongoDB\Configuration' like expected, but in getLoggerCallable() write 'Doctrine\MongoDB\Configuration'

Do you have any ideas about this behaviour?



 Comments   
Comment by Stanislav Korchagin [ 16/May/11 ]

The error was in my bootstrap code:

- $manager = \Doctrine\ODM\MongoDB\DocumentManager::create(
-           new \Doctrine\MongoDB\Connection(),
-            $config
-        );
+ $manager = \Doctrine\ODM\MongoDB\DocumentManager::create(
+           null,
+            $config
+        );

But confusion still exists, because I used an example from the documentation (http://www.doctrine-project.org/docs/mongodb_odm/1.0/en/reference/introduction.html#setup).





[MODM-142] DocumentRepository::findBy() not compatible with interface Created: 07/May/11  Updated: 07/May/11

Status: Open
Project: Doctrine MongoDB ODM
Component/s: Document Repositories
Affects Version/s: 1.0.0BETA3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jan Pieper Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I want to get a document repository for my Document\Event document class but instead i get a fatal error.

Pseudo
<?php

use Doctrine\MongoDB\Connection;
use Doctrine\ODM\MongoDB\DocumentManager;
use Doctrine\ODM\MongoDB\Configuration;
use Documents\Event;

$manager = new DocumentManager(
    new Connection(...),
    new Configuration(...)
);

$manager->getRepository('Documents\Event');

Fatal error: Declaration of Doctrine\ODM\MongoDB\DocumentRepository::findBy() must be compatible with that of Doctrine\Common\Persistence\ObjectRepository::findBy() in /home/jpieper/Workspace/Jersey/vendor/doctrine-common/lib/Doctrine/ODM/MongoDB/DocumentRepository.php on line 39

DoctrineCommonPersistenceObjectRepository.php (github@5a285537)
public function findBy(array $criteria, array $orderBy = null, $limit = null, $offset = null);
DoctrineODMMongoDBDocumentRepository.php (github@8d02e843)
public function findBy(array $criteria) { ... }

See https://github.com/doctrine/common/commit/5a2855372834cf37e0408e80dcb9a9c97ec1d352#lib/Doctrine/Common/Persistence






[MODM-141] Doctrine ODM: Documentation error Created: 26/Apr/11  Updated: 26/Apr/11

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

Type: Documentation Priority: Major
Reporter: Diego Lewin Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

not applicable



 Description   

I think that is a documentation issue, in http://www.doctrine-project.org/docs/mongodb_odm/1.0/en/reference/query-builder-api.html (15.3. Modifier Operations) the queries are like:

$dm->createQueryBuilder('User')

>field('password')>set('newpassword')

>field('username')>equals('jwage')

->getQuery()
->execute();

But it is missing the update(), it should be like:

$dm->createQueryBuilder('User')

->update()
>field('password')>set('newpassword')

>field('username')>equals('jwage')

->getQuery()
->execute();

All the queries in that section have similar issue






[MODM-116] Collection Per Class Inheritance : Documents of a child class referenced in a parent class may be saved to the parent collection Created: 07/Feb/11  Updated: 21/Apr/11

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

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


 Description   

Here is my class hierarchy (classes & attributes renamed for a better understanding) :

 
/** @Document @InheritanceType("COLLECTION_PER_CLASS") **/
class Parent {
    /** @ReferenceOne(targetDocument="Child") **/
    protected $child;
}

/** @Document **/
class Child extends Parent {
}

When doing :

$parent->setXXX($value);
$parent->getChild()->setXXX($value2)

the $parent->getChild() document is saved to the Parent collection.

It looks like the problems lies in UnitOfWork::executeUpdates :

 
if (get_class($document) == $className || $document instanceof Proxy && $document instanceof $className) {

$child_document is an instance of Proxy (ChildProxy) and also an instance of Parent => saved using the Parent persister.

Shouldn't the test be : get_class($document) == $className || get_class($document) == $className_of_Proxy ?

As a side note : why "if ($class->isEmbeddedDocument)

{ continue; }

" is within the foreach and not a "if ($class->isEmbeddedDocument)

{ return; }

" at the beginning of the method ?



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

I added a test for this here and it appears to be passing: https://github.com/doctrine/mongodb-odm/commit/3f24d77cc04adc0bb5532333e33826100457c666

Comment by JF Bustarret [ 11/Feb/11 ]

I'll try to get more info on the problem and provide a test for it.

Comment by JF Bustarret [ 28/Mar/11 ]

Here is a new test case :

 
/** @Document
 *  @InheritanceType("COLLECTION_PER_CLASS")
 **/
class MODM116Parent
{
    /** @Id */
    private $id;

    /** @String */
    private $name;

    /** @ReferenceOne **/
    private $child;

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

    public function getName()
    {
        return $this->name;
    }

    public function setName($name)
    {
        $this->name = $name;
    }

    public function getChild()
    {
        return $this->child;
    }

    public function setChild(MODM116Child $child)
    {
        $this->child = $child;
    }
}

/** @Document **/
class MODM116Child extends MODM116Parent
{
    
    /** @EmbedMany(targetDocument="MODM116Embedded") **/
    protected $embedded;
    
    function addEmbedded($parent) {
        $this->embedded[] = new MODM116Embedded($parent);
    }
}

/** @EmbeddedDocument **/
class MODM116Embedded {
    
    /** @ReferenceOne(targetDocument="MODM116Parent") **/
    protected $parent;
    
    public function __construct($parent) {
        $this->parent = $parent;
    }
    
}


$parent = new MODM116Parent();
$parent->setName('test');
$parent->setChild(new MODM116Child());
$dm->persist($parent->getChild());
$dm->persist($parent);
$dm->flush();
$dm->clear();

$parent = $dm->getRepository(get_class($parent))->findOneBy(array('name' => 'test'));

$parent->getChild()->setName('ok');
$parent->getChild()->addEmbedded($parent);
$dm->flush();
Comment by JF Bustarret [ 30/Mar/11 ]

Pulled the last version from git. The bug still exists.

Comment by JF Bustarret [ 21/Apr/11 ]

Up. Any news on a fix ?





[MODM-133] array keys with dots aren't persisted for Hash field Created: 21/Mar/11  Updated: 11/Apr/11  Resolved: 11/Apr/11

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

Type: Bug Priority: Major
Reporter: jules b Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

Macosx


Attachments: Zip Archive MODM133.zip     Zip Archive MODM133.zip    

 Description   

array keys with dots aren't persisted for Hash field

in the attachment you will find a complete testcase.

thanks.

EDIT: use the second attachment



 Comments   
Comment by jules b [ 11/Apr/11 ]

it seems that mongodb doesn't allow dots in keys.
http://shift8creative.com/blog/creating-a-simple-and-efficient-rating-system-with-mongodb





[MODM-139] [PATCH] @ReferenceMany with no referenceMapping cannot handle DBRef in all / in queries Created: 08/Apr/11  Updated: 08/Apr/11

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

Type: Bug Priority: Major
Reporter: Gérald Croes Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Linux, PHP 5.3



 Description   

I have thoose examples :

/** @Document 
 * @InheritanceType("SINGLE_COLLECTION")
 * @DiscriminatorField(fieldName="type")
 * @DiscriminatorMap({"Test\Product"="Product", "Test\Year"="Year"})
*/
Attributes {
   /** @Id */
   protected $_id;
}

/** @Document */
class Product extends Attributes {}

/** @Document */
class Year extends Attributes {}

/**
 * Classe de base pour les différents contenus
 * @Document
 * @InheritanceType("SINGLE_COLLECTION")
 * @DiscriminatorField(fieldName="type")
 * @DiscriminatorMap({"Test\Document"="Document", "Test\Infos"="Infos"})  
 */
class Content
{
   /** protected $_id */
    /** @ReferenceMany */
    protected $_attributes;
}

And the querying stuff

//and the query : 
$queryBuilder = $dm->createQueryBuilder('Test\DOcument');
//...
$attribute1Ref = $dm->createDBRef($attribute1Object);
$attribute2Ref = $dm->createDBRef($attribute2Object);
$queryBuilder->field('_attributes')->all(array($attribute1Ref, $attribute2Ref));
$queryBuilder->getQuery()->execute();//Won't work as the generated query won't specify the "_doctrine_class_name" value.

Proposed patch in DocumentManager :

    /**
     * Returns a DBRef array for the supplied document.
     *
     * @param mixed $document A document object
     * @param array $referenceMapping Mapping for the field the references the document
     *
     * @return array A DBRef array
     */
    public function createDBRef($document, array $referenceMapping = null)
    {
        $className = get_class($document);
        $class = $this->getClassMetadata($className);
        $id = $this->unitOfWork->getDocumentIdentifier($document);

        $dbRef = array(
            $this->cmd . 'ref' => $class->getCollection(),
            $this->cmd . 'id'  => $class->getDatabaseIdentifierValue($id),
            $this->cmd . 'db'  => $this->getDocumentDatabase($className)->getName()
        );

        // add a discriminator value if the referenced document is not mapped explicitely to a targetDocument
        if ($referenceMapping && ! isset($referenceMapping['targetDocument'])) {
            $discriminatorField = isset($referenceMapping['discriminatorField']) ? $referenceMapping['discriminatorField'] : '_doctrine_class_name';
            $discriminatorValue = isset($referenceMapping['discriminatorMap']) ? array_search($class->getName(), $referenceMapping['discriminatorMap']) : $class->getName();
            $dbRef[$discriminatorField] = $discriminatorValue;
+        }  elseif ($referenceMapping === null) {
+            $dbRef['_doctrine_class_name'] = $class->getName();
+        }
        return $dbRef;
    }





[MODM-138] Field's name attribute does not work for the update queries Created: 07/Apr/11  Updated: 07/Apr/11

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

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


 Description   

Documents

class Test 
{
.
.
.
/**
 * @EmbedOne(targetDocument="Location", name="l")
*/
private $location;
.
.
.
}

/** @EmbeddedDocument */
class Location
{
    /**
	 * @Field(type="float", name="y")
	 */
    public $lat;

    /**
	 * @Field(type="float", name="x")
	 */
    public $lng;

	public function __construct($latitude,$longitude) {
		$this->lat = $latitude;
		$this->lng = $longitude;
	}
}

Update query:

$dm->createQueryBuilder('Test')
->update()
->field('id')->equals(123)
->field('l')->set(new Location(39, 32);
->getQuery(array('upsert' => true))
->execute();

Result of this query is

"l": {
    "lat": 39,
    "lng": 32
},

however, it should be

"l": {
    "y": 39,
    "x": 32
},

also field function can support field name of the class on update queries, as follows

$dm->createQueryBuilder('Test')
->update()
->field('id')->equals(123)
->field('location')->set(new Location(39, 32);
->getQuery(array('upsert' => true))
->execute();





[MODM-137] Undefined index 'criteria' in DocumentPersister Created: 04/Apr/11  Updated: 04/Apr/11

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

Type: Bug Priority: Major
Reporter: Kevin Bradwick Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

On the master branch, a notice is thrown on line 531 of the DocumentPersister for an undefined index 'criteria'. This is when using the Yaml driver.

https://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php#L531

Full notice:
Notice: Undefined index: criteria in /Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php on line 531
PHP Warning: array_merge(): Argument #2 is not an array in /Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php on line 532

Warning: array_merge(): Argument #2 is not an array in /Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php on line 532
PHP Catchable fatal error: Argument 1 passed to Doctrine\MongoDB\Collection::find() must be an array, null given, called in Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php on line 533 and defined in Doctrine/MongoDB/Collection.php on line 169

Catchable fatal error: Argument 1 passed to Doctrine\MongoDB\Collection::find() must be an array, null given, called in Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php on line 533 and defined in /Doctrine/MongoDB/Collection.php on line 169






[MODM-136] Document's fields names are not properly converted to database names in a query Created: 27/Mar/11  Updated: 27/Mar/11

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

Type: Bug Priority: Major
Reporter: Eugene Leonovich Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Mappings:

/**
 * @Field(type="date", name="scheduled_at")
 */
private $scheduledAt;

/**
 * @Field(type="date", name="completed_at")
 */
private $completedAt;

Query:

$qb->field('scheduledAt')->lte($now)
   ->addOr($qb->expr()->field('completedAt')->lte($now))
   ->addOr($qb->expr()->field('completedAt')->equals(null))
   ->sort('scheduledAt', 'asc');

Expected result:

db.foo.find({
    "scheduled_at": { "$lte": new Date(...) }, 
    "$or": [ 
        { "completed_at": {  "$lte": new Date(...) } }, 
        { "completed_at": null } ] 
})
.sort({ "scheduled_at": 1 });

Actual result:

db.foo.find({
    "scheduled_at": { "$lte": new Date(...) }, 
    "$or": [ 
        { "completedAt": {  "$lte": new Date(...) } }, 
        { "completedAt": null } ] 
})
.sort({ "scheduledAt": 1 });





[MODM-135] [Cursor] ReferenceMany sort mapping not working Created: 25/Mar/11  Updated: 26/Mar/11

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

Type: Bug Priority: Major
Reporter: jules b Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Macosx


Attachments: Zip Archive MODM135.zip    

 Description   

I have a document like this:

/** @Document */
class Page
{
/** @Id */
protected $id;

/** @ReferenceMany(sort=

{"order"="asc"}

) */
protected $blocks;
}

If i have well understood things, i can do:

$blocks = $dm->getRepository('Page')>find($id)>getBlocks();

blocks should now be sorted by $order property.

This behaviour doesn't seems to work (or maybe i'm missing something).
In the attachment there's a test case

i made the priority major because in my case i haven't found a workaround (i'm using nested referenceMany, a child can have children, which can have children, ..).






[MODM-134] Reference added twice Created: 24/Mar/11  Updated: 25/Mar/11

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

Type: Bug Priority: Major
Reporter: jules b Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have a listener who listens on onFlush event,
i have a document and change a property (integer) in it and call $uow->recomputeSingleDocumentChangeSet().
The result is that all references are added twice.

If i remove the call to $uow->recomputeSingleDocumentChangeSet() all is fine.

Here's my document (notice references added twice on children property):

array (
'children' =>
array (
0 =>
array (
'$ref' => 'block',
'$id' => new MongoId("4d8b663638b6180803000005"),
'$db' => 'app_jules',
'_doctrine_class_name' => 'Design\\PageBundle\\Document
StrategyBlock',
),
1 =>
array (
'$ref' => 'block',
'$id' => new MongoId("4d8b663638b6180803000005"),
'$db' => 'app_jules',
'_doctrine_class_name' => 'Design\\PageBundle\\Document
StrategyBlock',
)
),
'order' => 0,
'parent' =>
array (
'$ref' => 'block',
'$id' => new MongoId("4d8b663638b6180803000003"),
'$db' => 'app_jules',
'_doctrine_class_name' => 'Design\\PageBundle\\Document
ContainerBlock',
),
'type' => 'container',
)

EDIT: if i clear() the $children ArrayCollection before calling $uow->recomputeSingleDocumentChangeSet() all is fine

I tried to reproduce it in a test-case but the result wasn't successful






[MODM-132] Doctrine\ODM\MongoDB\Mapping\ClassMetaData is loosing "file" property after serialization Created: 18/Mar/11  Updated: 18/Mar/11

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

Type: Bug Priority: Major
Reporter: Andrei S Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

After ClassMetaData is awakened it looses the "file" property and that breaks our File model.
File::count() returns 0

I dumped ClassMetaData object with caching enabled and disabled. Here's the diff:

146c146
< [file] =>

> [file] => file
149a150,180
> [0] => Array
> (
> [keys] => Array
> (
> [uploaded_at] => 1
> )
>
> [options] => Array
> (
> [safe] => true
> [unique] =>
> )
>
> )
>

The first line is the missing file value. The second block appears to be missing indexes but I'm guessing this information should not be serialized.






[MODM-131] Notice in Doctrine\MongoDB\GridFS::doInsert Created: 09/Mar/11  Updated: 09/Mar/11

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

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

CentOS 5.5, PHP 5.3



 Description   

Notice: Undefined variable: file in /projects/tbi/vendors/doctrine/odm/lib/vendor/doctrine-mongodb/lib/Doctrine/MongoDB/GridFS.php on line 112






[MODM-124] ClassMetadata shouldn't store defaultDb value Created: 18/Feb/11  Updated: 04/Mar/11  Resolved: 04/Mar/11

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

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


 Description   

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

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

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

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



 Comments   
Comment by Jonathan H. Wage [ 04/Mar/11 ]

Hi, this is fixed here https://github.com/doctrine/mongodb-odm/commit/6b91d944e68bbf94702a38351f03c74b7d6a057a

Thanks for reporting the issue.





[MODM-82] Add New Attribute "idGetter" to allow accessing the ID without triggering lazy-load Created: 29/Sep/10  Updated: 04/Mar/11

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

Type: New Feature Priority: Major
Reporter: Thomas Adam Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

access the ID of a proxy without loading it.

See DDC-687






[MODM-125] Doctrine\ODM\MongoDB\MongoCollection::findOne does not invoke postFindOne event handlers doing query against MongoGridFS collection Created: 18/Feb/11  Updated: 04/Mar/11  Resolved: 04/Mar/11

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

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

CentOS, PHP 5.3



 Description   

subj

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

thanks!



 Comments   
Comment by Vitaliy Kaplich [ 18/Feb/11 ]

And the same bug with Doctrine\ODM\MongoDB\MongoCollection::getDBRef method as well

Comment by Jonathan H. Wage [ 04/Mar/11 ]

Which version are you using? I don't see this behavior any longer. Can you confirm?

Comment by Jonathan H. Wage [ 04/Mar/11 ]

Also, getDBRef() notifies the pre/postGetDBRef events.

Comment by Jonathan H. Wage [ 04/Mar/11 ]

If you can still reproduce the issue can you provide a test case for us to run?

Comment by Vitaliy Kaplich [ 04/Mar/11 ]

I'm using 1.0.0BETA1

https://github.com/doctrine/mongodb-odm/blob/1.0.0BETA1/lib/Doctrine/ODM/MongoDB/MongoCollection.php

there is a "return" at line 338

so the function invoke "preFindOne" but not "postFindOne"





[MODM-105] inversedBy as ORM Created: 07/Jan/11  Updated: 04/Mar/11  Resolved: 04/Mar/11

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

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


 Description   

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



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

hmm. I am not sure if having inversedBy makes sense for the mongodb odm based on how references currently work. What would it be used for? relationships in the odm don't work like they do in the orm. We don't use foreign keys to get a reference, we store a reference document on the document that is doing the referencing.

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

Thinking about this more:

/** @Document */
class Product
{
    /** @ReferenceOne(targetDocument="Seller") */
    private $seller;
}

/** @Document */
class Seller
{
    /** @ReferenceMany(targetDocument="Product", inversedBy="seller") */
    private $products;
}

Now the $products association will be loaded by running a query like this:

db.products.find({ 'seller.$id' : seller.id })

Is this what you mean?

Comment by Henrik Bjornskov [ 20/Feb/11 ]

Sorry not getting back to you about this sooner. But that is exactly what i mean can also be done for reference one i think

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

Can you help me think through the other scenariors where it can be used? and how mappedBy would be used. We just need to be sure to think through all the semantics and define it all before I start trying to implement it.

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

I implemented this here https://github.com/doctrine/mongodb-odm/commit/d1bffbd6bb7b7b690e25f1314f1bf6b69f1e41a6

Can you check it out and give some feedback?

Comment by Henrik Bjornskov [ 21/Feb/11 ]

Yes i will play around with it later today





[MODM-130] @ChangeTrackingPolicy notation is ignored in @MappedSuperclass Created: 02/Mar/11  Updated: 02/Mar/11

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

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

CentOS 5.5, PHP 5.3



 Description   

I am not sure if it's supposed to be that @MappedSuperclass document can define @ChangeTrackingPolicy for multiple documents but in fact it does not work.

In other words in the case below:
===================================================

/**

  • @MappedSuperclass
  • @InheritanceType("COLLECTION_PER_CLASS")
  • @ChangeTrackingPolicy("DEFERRED_EXPLICIT")
    */
    abstract class MappedDocument
    {
    }

/**

  • @Document(collection="chart")
    */
    class Chart extends MappedDocument
    {
    }

===================================================

class Chart

  • has InheritanceType = INHERITANCE_TYPE_COLLECTION_PER_CLASS which is expected
  • but ChangeTrackingPolicy = CHANGETRACKING_DEFERRED_IMPLICIT (value by default) which is NOT expected.

At the same time if to define ChangeTrackingPolicy in the Chart class instead of MappedDocument it works as expected.






[MODM-129] Storing embeded documents containing embeded documents, already persistet in another collection fails Created: 25/Feb/11  Updated: 25/Feb/11

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

Type: Bug Priority: Major
Reporter: Kolja Treutlein Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: GZip Archive testcase.tar.gz    

 Description   

We persist a document a1 containing an embedded document a1.1 which itself contains another embedded document a1.1.1. When the embedded document a1.1 is moved to another document of another collection b1 and needs to get persisted as embedded document b1.1 the embedded document a1.1.1 (which is now part of b1.1, too) is not saved as an embedded document of b1.1.

Example: We use a version object which contains a pageversion as an embedded document. This page object contains multiple elements (stored as embedded documents) which themselves contain several parameter objects (stored as embedded document of elements). Now assume we have such a persisted version and want to "copy" the pageversion in another collection. So we generate a new page object, and add to this page all elements of the persisted pageversion. If we now persist this page, the representation in mongodb contains all elements but not any parameters, which should be part of the page as well (as they are part of an element).



 Comments   
Comment by Kolja Treutlein [ 25/Feb/11 ]

Testcase

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

Try cloning the embedded document when you move it. The reason why you have issues most likely is because internally inside Doctrine we keep track of each embedded document instance and what parent document it is attached to. So when you move it, Doctrine gets confused. You need to move it by cloning so the embedded document is actually a new object instance to Doctrine.





[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-128] Upserts in Query builder Created: 23/Feb/11  Updated: 23/Feb/11

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

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

Mac OS X + MAMP



 Description   

It seems that if you just call upsert(true) in a update request, it won't be enough. You have to calm getQuery(array('upsert' => true)) as well in order to have the 'insert if not exist' working.






[MODM-127] Update queries : update() required ? Created: 23/Feb/11  Updated: 23/Feb/11

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

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


 Description   

In the documentation exemples for update queries :
http://www.doctrine-project.org/docs/mongodb_odm/1.0/en/reference/query-builder-api.html#update-queries

it doesn't mention a update() function call any more in update queries.

Did I miss something?






[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-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-53] Problems with querying referenced elements Created: 18/Aug/10  Updated: 19/Feb/11  Resolved: 18/Aug/10

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

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


 Description   

When trying to query embedded objects, I can use this syntax:

object.value = "asd"

but when I reference a different collections object, this would give me no result.

However, according to http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-Embedvs.Reference this should work the same way.



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

Can you be more specific what your issue? I can't quite understand what you mean. If you are asking if you can query a referenced document like you can an embedded document, the answer is no.

i.e. if you have a document like this:

array('username' => 'jwage', 'profile' => array(...dbref....))

You can't query something like "profile.someFieldName" which exists on the referenced document.

Comment by Sebastian Hoitz [ 18/Aug/10 ]

But is this a limitation of Doctrine ODM or of MongoDB?

Could there be a work-around for this issue? I can see quite a lot of cases where this might be important to do.

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

It is the way MongoDB works, you have to think about how this is actually being stored and how the dot annotation works for querying. It only works with embedded documents, and the fields of the referenced document aren't embedded, they live somewhere else on another collection and the data is loaded in PHP with another query to mongo.





[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-122] array_slice fails on ReferenceMany and EmbeddedMany fields Created: 17/Feb/11  Updated: 17/Feb/11  Resolved: 17/Feb/11

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

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

CentOS, PHP 5.3



 Description   

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

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

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

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

Thanks a lot!



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

Hi, you need to pass an array so you can convert the iterator to an array with the iterator_to_array() method or call ->toArray() on the PersistentCollection. Then you can pass that array to array_slice()





[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-120] [Configuration] problem with changing the defaultDB Created: 15/Feb/11  Updated: 16/Feb/11  Resolved: 16/Feb/11

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

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


 Description   

What i want to do is to change the database name of the document manager:

$config = new Configuration();
$dm = new DocumentManager($conn, 'my_db', $config);

$config->setDefaultDB('another_db');
$dm->getDatabase(); // 'my_db' insteadof 'another_db'

Is there another solution to do this ?



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

Hi, i reverted the change that caused these problems so it should be all good now.





[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-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-78] mappedSuperclass as parent embedded class Created: 13/Sep/10  Updated: 11/Feb/11  Resolved: 11/Feb/11

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

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


 Description   

Hi,

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

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

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

DomainAbstract is defined as mappedSuperclass

Address is defined as mappedSuperclass

PersonalAddress, ProfessionalAddress are embeddedDocument

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

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

thx for help

ps: yaml mapping



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

Could you provide a test case or the files you are using to produce the problem?





[MODM-102] Documents which belong to global namespace can not be handled? Created: 16/Dec/10  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: None

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

CentOS 5.5, PHP 5.3.3



 Description   

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

So lets say I created the following configuration file:

.Blackboard_Page.dcm.xml

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

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

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

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

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

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

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



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

When you omit the starting \ does that help? I don't think you need to include it.

Comment by Vitaliy Kaplich [ 21/Dec/10 ]

Ok. I'll keep in mind and try later when it become possible and let you know about the result.

> I don't think you need to include it.

Unfortunately right now I just can not check it.





[MODM-104] Creating mongo configuration class instance hangs php Created: 21/Dec/10  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: None

Type: Bug Priority: Major
Reporter: Peter Jasiulewicz Assignee: Jonathan H. Wage
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Ubuntu 10.4, PHP 5.3.3, MongoDB 1.6.5, doctrinemongoODM installed with PEAR, also present Doctrine 1.2.3, php handling installed via pecl



 Description   

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

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

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

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

No errors or warnigs of any kind generated.



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

Hmm, I am not sure this is a problem with any code or anything in the odm, but something wrong with your environment maybe?

Comment by Peter Jasiulewicz [ 24/Dec/10 ]

No reason why it would hang on a simple object constucting. I'm using the box for development for a while now, Doctrine 1.2.3 installd too.
Will try to change the box after Xmas.





[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-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-109] Reference with Inheritance: Proxy error: 'document with identifier .. could not be found' Created: 24/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: None

Type: Bug Priority: Major
Reporter: jules b Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

Mac osx


Attachments: File InheritanceReference.tgz    

 Description   

It's hard to explain this issue,

I have a single table Inheritance, the base class is Block. ContainerBlock is a child class of Block.
I have a document Page who have a one-one with ContainerBlock (child of Block). ContainerBlock as many Block.

  • Test script:
    ----------------

I have created a complete test-case (see attachment).
phpunit InheritanceReference/InheritanceReferenceTest.php

  • Expected result:
    -----------------------

no error, no exception.

  • Actual result:
    -------------------

1) InheritanceReference\InheritanceReferenceTest::testMulipleInheritance
Doctrine\ODM\MongoDB\MongoDBException: The "Proxy\DocumentBlockProxy" document with identifier "4d3d08116aba269508000001" could not be found.

src/vendor/symfony/vendor/doctrine-mongodb-odm/lib/Doctrine/ODM/MongoDB/MongoDBException.php:69
src/Bundle/InheritanceReference/Proxy/DocumentBlockProxy.php:25
src/Bundle/InheritanceReference/Proxy/DocumentBlockProxy.php:34
src/Bundle/InheritanceReference/InheritanceReferenceTest.php:65



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

In your annotations you have @mongodb: but for just a standalone Doctrine test you don't need that. When I corrected the annotations no problem existed.





[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-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-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-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-117] "name" attribute in @Field annotation 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: None

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

CentOS 5.5, PHP 5.3



 Description   

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

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

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

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

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

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

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

{'_'.$propertyName};
}

public function __set($propertyName, $propertyValue)
{
$this->{'_'.$propertyName}

= $propertyValue;
}
}

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



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

I added a test here for your issue and it appears to be working properly in the latest master in git.

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





[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-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-115] Persisting a document which references another document drops ID Created: 03/Feb/11  Updated: 03/Feb/11  Resolved: 03/Feb/11

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

Type: Bug Priority: Major
Reporter: Robert Knutsson Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

Debian, PHP 5.3.3-7 Suhosin fcgi



 Description   

I have two documents:

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

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

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

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

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

$inserts[$oid] = $data;

where $data is:

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

and $inserts[$oid] becomes:

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

This assignment makes the MongoID disappear somehow!!?

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



 Comments   
Comment by Robert Knutsson [ 03/Feb/11 ]

The problem occurred since i was dumping the class before it was initialized, not realizing that proxy classes lazy loaded.





[MODM-108] Random hydratation problem Created: 23/Jan/11  Updated: 25/Jan/11  Resolved: 25/Jan/11

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

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

Mac OS X



 Description   

I have the following collection named Isboo_Item :

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

I have a such PHP class :

/**

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

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

I get :

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

However the same works fine with another collection :

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

{ "mana": 64, "strenght": 83, "agility": 69, "dexterity": 88, "constitution": 94, "culture": 79, "vivacity": 57, "eloquence": 64, "intellect": 74, "willpower": 88, "empathy": 96, "charisma": 83 }

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

{ "IDplace": 0, "posX": 0, "posY": 0, "posLocalX": 0, "posLocalY": 0 }

,
"refFather":

{ "$ref": "Isboo_Character", "$id": ObjectId("4d3cf450b532519765090000"), "$db": "Isboona" }

,
"refMother":

{ "$ref": "Isboo_Character", "$id": ObjectId("4d3cf450b5325197650a0000"), "$db": "Isboona" }


}






[MODM-96] YamlDriver Symfony Components Namespace Issue Created: 25/Nov/10  Updated: 20/Dec/10  Resolved: 20/Dec/10

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

Type: Bug Priority: Major
Reporter: Nashad Alam Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

Ubunuto, Zend Server, MongoDB 1.6.3



 Description   

In the YamlDriver.php the namespace is incorrect I pressume. It should be \Symfony\Components\Yaml\Yaml. Its missing a 's' in Component

Current in Master :
protected function loadMappingFile($file)
{
return \Symfony\Component\Yaml\Yaml::load($file);
}

Desired Outcome
protected function loadMappingFile($file)
{
return \Symfony\Components\Yaml\Yaml::load($file);
}



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

Hi, no they renamed it to Component. No "s". Do you have an old version of the YAML component maybe?





[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-98] Partial UnitOfWork clear on runtime defaultDb change Created: 08/Dec/10  Updated: 20/Dec/10  Resolved: 20/Dec/10

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

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


 Description   

Actually I am not sure if this is a bug or just ODM limitation, but there is a use-case for MongoDb which doesn't fit well with current ODM implementation.

Imagine SaaS service, where each client has his own DB. Documents and collections are all the same, except most of them are stored in different DBs, depending on context.

It works pretty well with ODM defaultDB configration setting, until you need to process data from different dbs (e.g. iterate db by db in CLI script). When you try to change default db, repositories and persisters stay there and all keep a reference to initial DB. And they don't get reset on UnitOfWork->clear(). It would be great to have runtime defaultDb switching out of the box, but if that is a problem, maybe you can advice on how this could be handled?



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

Hi, this is actually by design. The configuration is not something you change at runtime. I think in your case you need to be working with multiple DocumentManager instances.





[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-103] @File tag support in xml notation Created: 20/Dec/10  Updated: 20/Dec/10  Resolved: 20/Dec/10

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

Type: Bug Priority: Major
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 @File tag (Mongo GridFS indicator) is not supported by xmlDriver.
I could not find anything about this feature neither in unitests for the system nor in documentation (as concerning the code probably I missed something but I also could not find anything related to GrisFS in xmlDriver code) .



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

You would just do this:

<field fieldName="photo" type="file" />




[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-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-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-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-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-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-73] Neo4j (Graph oriented Database) Created: 06/Sep/10  Updated: 24/Nov/10  Resolved: 24/Nov/10

Status: Closed
Project: Doctrine MongoDB ODM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None

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

Multiplatform



 Description   

MongoDB Object Document Mapper is a particularly nice added value and represent a great interest for integrating into php framework.
MongoDB is one of the most representative actor in the document oriented databse and my suggestion here would be to implement
the same for the most representative graph oriented database which is Neo4J.

Someone tried an overall PHP approach and his choice seems an interesting compromise => http://wiki.neo4j.org/content/PHP.
A more elaborated approach around a doctrine work would be ore than helpful.



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

Hi, it sounds interesting! As of right now all the members of the Doctrine team are pretty busy with the existing projects and integrations. We would gladly consider accepting a contribution for another Doctrine library that follows the Doctrine2 style persistence layer. Maybe you and some others could work on something? or you could try and raise interest in it?

Comment by Alexandre Emeriau [ 06/Sep/10 ]

Yes, that's absolutely the approach to follow as the doctrine team is busy. I will definitely try this once my skills will be enough in this area.





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





[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-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-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-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-83] UnitOfWork incorrectly updates all documents with embedded documents on flush Created: 30/Sep/10  Updated: 19/Oct/10  Resolved: 04/Oct/10

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

Type: Bug Priority: Major
Reporter: Justin Hileman Assignee: Bulat Shakirzyanov
Resolution: Fixed Votes: 1
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   

UnitOfWork incorrectly contains every managed document with embedded documents. All embedded documents are marked as updated. The whole mess will be updated on the next flush, regardless of whether said documents have actually changed.

Branch here: http://github.com/opensky/mongodb-odm/tree/MODM-83

Test case here: http://github.com/opensky/mongodb-odm/commit/af4373b58dd5da0bea5a0f8c4da30dde5ed1f266

Here's what the document changeset looks like in preUpdate and postUpdate:

preUpdate "Doctrine\ODM\MongoDB\Tests\Functional\Ticket\MODM83OtherDocument"

array(1) {
  ["name"]=>
  array(2) {
    [0]=>
    string(8) "Neighbor"
    [1]=>
    string(3) "Bob"
  }
}

postUpdate "Doctrine\ODM\MongoDB\Tests\Functional\Ticket\MODM83OtherDocument"

array(1) {
  ["name"]=>
  array(2) {
    [0]=>
    string(8) "Neighbor"
    [1]=>
    string(3) "Bob"
  }
}

preUpdate "Doctrine\ODM\MongoDB\Tests\Functional\Ticket\MODM83TestDocument"

array(1) {
  ["embedded"]=>
  array(2) {
    [0]=>
    array(1) {
      ["name"]=>
      string(5) "Child"
    }
    [1]=>
    array(2) {
      ["name"]=>
      string(5) "Child"
      ["originalObject"]=>
      object(Doctrine\ODM\MongoDB\Tests\Functional\Ticket\MODM83TestEmbeddedDocument)#86 (1) {
        ["name"]=>
        string(5) "Child"
      }
    }
  }
}

postUpdate "Doctrine\ODM\MongoDB\Tests\Functional\Ticket\MODM83TestDocument"

array(1) {
  ["embedded"]=>
  array(2) {
    [0]=>
    array(1) {
      ["name"]=>
      string(5) "Child"
    }
    [1]=>
    array(2) {
      ["name"]=>
      string(5) "Child"
      ["originalObject"]=>
      object(Doctrine\ODM\MongoDB\Tests\Functional\Ticket\MODM83TestEmbeddedDocument)#86 (1) {
        ["name"]=>
        string(5) "Child"
      }
    }
  }
}


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

Fixed here http://github.com/doctrine/mongodb-odm/commit/8bd3aef4055cfded62687d5ad0e762e3f12a473d

Comment by Alexander Koß [ 19/Oct/10 ]

I use this update, 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, i hope you can fix it, not my english, the bug.

Comment by Alexander Koß [ 19/Oct/10 ]

I have create a new issue: MODM-89





[MODM-76] I get an error when trying to persist a document Created: 11/Sep/10  Updated: 20/Sep/10  Resolved: 20/Sep/10

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

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


 Description   

This is the error I get:

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

Stack Trace:

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

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



 Comments   
Comment by Sebastian Hoitz [ 11/Sep/10 ]

I got the latest version from Github and this error still occures.

I also checked with my models. Before persisting my model with Doctrine all the referenced models are Documents. Somewhere in the Persister the model has to get changed to an array.

Comment by Sebastian Hoitz [ 11/Sep/10 ]

The issue seems to be in this http://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php#L419 method.

When calculating the changeset we end up with an array. When this array is passed on to prepareValue in http://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/Persisters/BasicDocumentPersister.php#L464 this method can not handle the array.

I hope this helps a bit with pinpointing the error.

Comment by Sebastian Hoitz [ 13/Sep/10 ]

I changed the prepareReferencedDocValue method in BasicDocumentPersister.php to this:

private function prepareReferencedDocValue(array $referenceMapping, $document)
	{
		$id = null;

		if (is_array($document))
		{
			$className = $referenceMapping['targetDocument'];
		}
		else
		{
			$className = get_class($document);
			$id = $this->uow->getDocumentIdentifier($document);
		}

		$class = $this->dm->getClassMetadata($className);

		if (null !== $id)
		{
			$id = $class->getDatabaseIdentifierValue($id);
		}
		$ref = array(
				$this->cmd . 'ref' => $class->getCollection(),
				$this->cmd . 'id' => $id,
				$this->cmd . 'db' => $class->getDB()
		);
		if (!isset($referenceMapping['targetDocument']))
		{
			$discriminatorField = isset($referenceMapping['discriminatorField']) ? $referenceMapping['discriminatorField'] : '_doctrine_class_name';
			$discriminatorValue = isset($referenceMapping['discriminatorMap']) ? array_search($class->getName(), $referenceMapping['discriminatorMap']) : $class->getName();
			$ref[$discriminatorField] = $discriminatorValue;
		}
		return $ref;
	}

and this seems to solve the issue.

However, I was not able to get the whole Doctrine ODM unit testing set up, so I could not check if all unit tests still pass.

I would love if somebody could help me getting the github and unit testing environment for Doctrine set up, so that I can work on some issues too!

Comment by Sebastian Hoitz [ 20/Sep/10 ]

Resolved with this commit:

http://github.com/sebastianhoitz/mongodb-odm/commit/9ec340697b184284f420e077457127f3147566e0

Includes test case to reproduce the issue.





[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-71] "Getting Started" Canonical example is needlessly confusing Created: 02/Sep/10  Updated: 03/Sep/10  Resolved: 02/Sep/10

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

Type: Improvement Priority: Minor
Reporter: cainiac Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

Ubuntu 10.04
PHP 5.3.2



 Description   

http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/introduction/en#introduction

The '/path/to/doctrine/' placeholders are nondescript and confusing to new users, especially when the only way to make them work is to pass in just the path to the DocumentRoot. That should be mentioned, cleaned up, re-purposed, re-clarified, reverted, or whichever adjective of adjustment is suitable.



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

I don't understand, why did you open this then mark it as invalid? I agree the documentation needs some work, the code has been in heavy development and we try and make the documentation good, but it lacks and gets out of date sometimes.

Anyways, I have to be honest your tone here just really irritated to me. Not just irritated, but made me angry. It comes off rude using words like "hideous", "God awful" and other smart ass comments. Remember this is open source, if you don't like something, either make your suggestion in a non asshole way and move on or clone the documentation and fix it yourself!

Thanks, Jon

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

Does this change help? http://github.com/doctrine/mongodb-odm-documentation/commit/a71440c84b013589277636db4992caf64c71c83e

http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/introduction/en#introduction

Comment by cainiac [ 03/Sep/10 ]

You sexy man, had I encountered that yesterday, I would have been flying through the setup process!

Sorry for the pissy tone in the beginning... my default literary stance is vitriolic polemics and I try my best (and fail) to keep it tucked away. :X

The elaboration and the follow-up example at the end will certainly assist future users in gracefully integrating this great solution to their shops.

Thanks, John!





[MODM-67] EmbeddedDocument - no LifecycleCallbacks Created: 31/Aug/10  Updated: 31/Aug/10  Resolved: 31/Aug/10

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

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


 Description   

LifecycleCallbacks in EmbeddedDocument are not called

/**
 * @EmbeddedDocument
 * @HasLifecycleCallbacks
 */
class SocialNetworkUser {

	/**
	 * @Int(name="id")
	 * @var int
	 */
	protected $id;
	/**
	 * @String(name="fN")
	 * @var string
	 */
	protected $firstName;
	/**
	 * @String(name="lN")
	 * @var string
	 */
	protected $lastName;
	/**
	 * @NotSaved
	 * @var string
	 */
	protected $name;

        // ....

	/**
	 * @PostLoad
	 */
        public function postLoad() {
		$this->name = $this->firstName . ' ' . $this->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' => $uid));
print_r($_user->getSocialNetworkUser()->getName())

$name is empty.
postLoad is never called after load



 Comments   
Comment by Thomas Adam [ 31/Aug/10 ]

Sorry, my mistake.
I have forgotten "callbacks" in cascade attribute .





[MODM-60] Need a way to find all documents from collection by their base class Created: 26/Aug/10  Updated: 31/Aug/10  Resolved: 30/Aug/10

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

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


 Description   

Imagine a use case:

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

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

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

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

and Doctrine would instantiate proper classes for found documents.

Is it possible?



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

It is possible if you have a none abstract parent class that all other subclasses extend from. If you query that class the queries will include a $in query limiting the results to itself and all subclasses using the discriminator values.

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

Actually it should work even if it is abstract. It just must be a mapped document that has a discriminatorMap specified.

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

This should work. You can ask usage questions on the mailing list and open an issue for bugs or enhancements.

Comment by Vladimir Razuvaev [ 31/Aug/10 ]

Yes, I checked. it works for non-abstract classes, with condition that queried class is in DiscriminatorMap for given collection.

But it forces me to rework classes hierarchy to be able to use this feature. I think it would be great to have it work with abstract classes in future versions of ODM.





[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-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-64] @DynamicFields Created: 28/Aug/10  Updated: 30/Aug/10  Resolved: 30/Aug/10

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

This would greatly enhance the flexibility of document mappers



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

Nice idea! So something like this could essentially work:

/** @Document */
class User
{
    /** @DynamicFields */
    public $data;
}

$user = $dm->find(....);
echo $user->data['username'];

I am not sure if it is a good idea to just allow them to use a single @DynamicFields, maybe we should throw an exception if they use it that way? Also, if they modify a value inside $data should we persist the changes?

Comment by Benjamin Eberlei [ 28/Aug/10 ]

i guess the semantics should be, just one dynamic fields per entity allowed and that is inlined into the "normal" fields using array_merge() ?

Comment by Benjamin Eberlei [ 29/Aug/10 ]

ok maybe array_merge() is a bit dangerous, when the dynamic field has a property named like a real property.

But you could do $data = array_merge($dynamicData, $staticData); and should be fine then semantically, of course this should be documented

I think you should have at least an ID or not? but something like this would even be very fast for prototyping:

/** @Document */
class User
{
    /** @Id @Field */
    private $id;

    /** @DynamicFields */
    public $data;
}
Comment by Jonathan H. Wage [ 29/Aug/10 ]

After thinking about it and discussing it I think the @Collection type can do what is needed:

/** @Document */
class User
{
    /** @Id */
    private $id;

    /** @Collection */
    public $data = array();
}




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