Doctrine Project

[MODM-93] YAML and XML mapping drivers ignore discriminatorField and discriminatorMap

Wed, 24 Nov 2010 13:13:32 +0000

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

[MODM-10] Missing use statement in UnitOfWork

Wed, 9 Jun 2010 19:50:51 +0000

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.

[MODM-9] Unexpected: MappedSuperclass private property without annotation becomes persisted

Wed, 9 Jun 2010 19:50:37 +0000

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

[MODM-8] custom repositories don't work when setting MetadataCacheImpl

Mon, 2 Aug 2010 17:27:24 +0000

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

[MODM-7] Fatal error when using a custom repository class in AnnotationDriver

Wed, 9 Jun 2010 19:50:01 +0000

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

[MODM-6] Error In Documentation

Wed, 9 Jun 2010 19:49:49 +0000

@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

[MODM-5] Make embedding work on objects in a collection inheritance tree

Wed, 9 Jun 2010 19:49:27 +0000

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

[MODM-4] tweak xml/yml syntax

Wed, 9 Jun 2010 19:48:57 +0000

[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

[MODM-3] API design

Wed, 9 Jun 2010 19:48:43 +0000

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)

[MODM-2] Reconsider the naming

Wed, 9 Jun 2010 19:48:14 +0000

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.

[MODM-1] Using Doctrine\Common\Collections\Collection

Wed, 9 Jun 2010 19:47:41 +0000

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.