[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-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-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-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-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-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-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-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-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-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-31] Cannot use a document against multiple classes Created: 29/Jul/10  Updated: 30/Jul/10  Resolved: 30/Jul/10

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

Type: Improvement Priority: Major
Reporter: Scott Aubrey Assignee: Jonathan H. Wage
Resolution: Invalid Votes: 0
Labels: None
Environment:

Mac OS X 10.6.4, Built in PHP with extra modules:
zend_extension=xdebug.so
extension=mongo.so
extension=mssql.so
extension=xdiff.so
extension=pcntl.so
extension=imap.so
extension=mcrypt.so

Doctrine Commond/DBAL/ODM from git



 Description   

It would be useful to be able to use two classes on one document, in a way that transparently extends the original schema. My use case:

I have a base Application that manages users of the system. A module/plugin to the system wants to extend the User records to include references to one of it's documents:

namespace Application\Model;
class User {
//user properties here
}

...

namespace Organisation\Model;
use Application\Model\User as BaseUser;

class Organisation {
//organisations properties
}

class User extends BaseUser {
/** @ReferenceOne(targetDocument="\Organisation\Model\Organisation") */
protected $organisation
}

It this theoretical scenario, the original \Application\Model\User needs to be used by the base application, but the \Organisation\Model\User can be used by the addon module to transparently add more data to the same user. The base class doesn't need to know it will be used this way.

Current behaviour for the above will ignore the additional properties not available in the parent class, and doesn't throw any exceptions/errors.

Other ways to make it work involve the base class knowing it will be extended via SCI, or using a mappedsuperclass?, which isn't transparent in the base class, it needs to be altered to work with it's children.



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

We have inheritance options that will allow that. Wouldn't this do the trick?

namespace Application\Model;

/** @MappedSuperclass(collection="users") */
class BaseUser
{
    // ...
}

/** @Document */
class User extends BaseUser
{
    // ...
}

namespace Organisation\Model;

use Application\Model\BaseUser;

/** @Document */
class User extends BaseUser
{
    // ...
}




[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-18] All Document object properties are persisted regardless of mapping instructions. Created: 20/Jun/10  Updated: 13/Jul/10  Resolved: 13/Jul/10

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

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

ubuntu, php 5.3.2, odm 1.0.0ALPHA1



 Description   
User Model
class Users_Model_User
{
    public $id;
    public $username;
    public $password;
    public $myRuntimeProperty = 'some value';
}
Document Mapping (in YAML)
Users_Model_User:
db: my_db
collection: users
fields:
    id:
        fieldName: id
        id: true
    username:
        fieldName: username
        type: string
    password:
        fieldName: password
        type: string
My test code
$user = new Users_Model_User;
$user->username = 'hello';
$user->password = 'world';
$this->dm->persist($user);
$this->dm->flush();

The result is "myRuntimeProperty" is saved to the db.
This causes problems for several properties such as "_propertyChangedListeners" which, once saved and later loaded back from the database, overrides the array of object listeners with a string of "Array"

If this is not a bug:
I have search everywhere for an answer. All the docs, mailing list, irc, blogs. If this is not a bug the solution needs to be better documented.

Temporary fix:
Use Docblock Annotations, set the unwanted properties with @NotSaved
(Unless there is also a way to set NotSaved using YAML?)



 Comments   
Comment by Rabbit [ 20/Jun/10 ]

I see how I was mistaken on this issue.

Conceptually, marking any property as "transient" therefore preventing the data from persisting makes sense. In practice, I wonder if it would be possible to set the default behavior to transient on all fields unless otherwise stated.

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

Right now it cannot be customized. It always persist every property unless otherwise specified.

Comment by Bulat Shakirzyanov [ 06/Jul/10 ]

this should be resolved in the current trunk

Comment by Bulat Shakirzyanov [ 13/Jul/10 ]

all the magic was removed





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





Generated at Mon Sep 01 13:44:04 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.