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

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

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

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

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

The UnitOfWork.php class has several references to LifecycleEventArgs but has no 'use' statement for it. This causes syntax errors when trying to use lifecycle events.

/** @MappedSuperclass */
class Model {

    private $errors = array();

    protected function getErrors() {
        return $this->errors;
    }
}

/**
 * @Document(db="mydb", collection="data")
 */
class Data extends Model {
    /**
     * @Id
     */
    public $id;

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

Did not expect, that $errors goes into mongo.

When I enable metadataCache:

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

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

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

Cheers, Onno

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

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

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

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

solves this issue..
Cheers, Onno

@see http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/cookbook/getting-started/en

The Doctrine\Common\Annotations\AnnotationReader requires an instance Doctrine\Common\Cache\Cache to be passed to it on construction. In the documentation above it is constructed with no such instance.

Regards,

Sam

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

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

I know I am nit-picky, I'm really just trying to help, but I think methods like save() that were recently added are just API bloat since all it does is persist + flush. The naming is also confusing, having both save and persist. If you really want to add a method to the public API to exchange 2 lines in user code against 1 line, then at least a more descriptive name would be better, like persistAndFlush().

API design is difficult, don't take it too lightly (thats what php did, heh)

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

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

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

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

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

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

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

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