[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-10] Missing use statement in UnitOfWork Created: 05/Jun/10  Updated: 09/Jun/10  Resolved: 06/Jun/10

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

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


 Description   

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.



 Comments   
Comment by Steven Surowiec [ 05/Jun/10 ]

Fixed in the below commit:

http://github.com/opensky/mongodb-odm/commit/865527aa3403a1fd9f8acdddd0584e1b1e74438a

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

Thanks for the issue and topic branch! Merged!





[MODM-9] Unexpected: MappedSuperclass private property without annotation becomes persisted Created: 03/Jun/10  Updated: 09/Jun/10  Resolved: 03/Jun/10

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

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

OS X, latest ODM checkout



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



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

This is expected behavior. It was changed so that all properties are persisted unless specified otherwise. Map the property is @Transient and it will be ignored by Doctrine:

class MyDocument
{
    // ...

    /** @Transient */
    private $errors = array();
}
Comment by Florian Kubis [ 04/Jun/10 ]

Thanks, this works.
Just to complete this issue, for now documentation of @Transient is missing in the reference.
http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/annotations-reference/en

Comment by Jonathan H. Wage [ 04/Jun/10 ]

Thanks. I have updated the documentation with the new @Transient annotation.





[MODM-8] custom repositories don't work when setting MetadataCacheImpl Created: 22/May/10  Updated: 02/Aug/10  Resolved: 03/Jun/10

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

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


 Description   

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



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

When you enable your metadata cache, it is pulling your mapping information from the cache instead of from your files. So it is probably pulling an older version that does not have the customRepositoryClassName property populated. Clear your metadata cache and it should work fine.

Comment by Onno Schmidt [ 02/Aug/10 ]

Somehow, I am still not able to get this to work. Even when I clear the cache I get the message that my custom methods can't be found. I will try to create reproducible case.





[MODM-7] Fatal error when using a custom repository class in AnnotationDriver Created: 16/May/10  Updated: 09/Jun/10  Resolved: 20/May/10

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

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


 Description   

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 Created: 16/May/10  Updated: 09/Jun/10  Resolved: 20/May/10

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

Type: Improvement Priority: Trivial
Reporter: Sam Smith Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None


 Description   

@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



 Comments   
Comment by Bulat Shakirzyanov [ 16/May/10 ]

check this out - http://github.com/jwage/doctrine2/blob/master/lib/Doctrine/Common/Annotations/AnnotationReader.php#L65
as you can see, the $cache in the __construct, is defaulted to null, which makes it unnecessary to pass cache instance to the constructor, in which case \Doctrine\Common\Cache\ArrayCache will be used.





[MODM-5] Make embedding work on objects in a collection inheritance tree Created: 14/May/10  Updated: 09/Jun/10  Resolved: 29/May/10

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

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


 Description   

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



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

Can you make a Doctrine test case that I can run more easily? and maybe some information about the issue?





[MODM-4] tweak xml/yml syntax Created: 11/May/10  Updated: 09/Jun/10  Resolved: 12/May/10

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

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


 Description   

[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



 Comments   
Comment by Bulat Shakirzyanov [ 12/May/10 ]

fixed it yesterday





[MODM-3] API design Created: 30/Apr/10  Updated: 09/Jun/10  Resolved: 30/Apr/10

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

Type: Improvement Priority: Minor
Reporter: Roman S. Borschel Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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)



 Comments   
Comment by Roman S. Borschel [ 30/Apr/10 ]

I think it just really helps ease of use if we keep the different APIs as similar as possible. Of course each can have their own methods, classes etc. We should just not overload the same names with completely different meanings in the different APIs.

Concerning this example, it just doesnt look very streamlined if there are such minor extra methods like save/persistAndFlush that you don't have in the other APIs and are neither mongo-specific (mongo-specific methods are fine!). Of course we don't want to fit the same API on all these projects, they should just not be too different in weird ways, like additional non-project-specific convenience methods that are available in one project but not in the other.

I hope I explained that well. It's just about a polished API feeling when using the different Doctrine projects.

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

I had the same thought when I was adding it and I wobbled back and fourth. Now that you say this I agree we should remove it.





[MODM-2] Reconsider the naming Created: 30/Apr/10  Updated: 09/Jun/10  Resolved: 30/Apr/10

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

Type: Task Priority: Major
Reporter: Roman S. Borschel Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



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

Agreed. This is great to have you here to provide this kind of valuable input!





[MODM-1] Using Doctrine\Common\Collections\Collection Created: 30/Apr/10  Updated: 09/Jun/10  Resolved: 11/May/10

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

Type: Task Priority: Major
Reporter: Roman S. Borschel Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



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

I implemented the base usage of the Collection stuff instead of php arrays. I will need your input on the best way to eliminate the loadEntityAssociation(s)() stuff and do something more transparent.





Generated at Wed Jul 30 23:25:50 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.