Mongodb 1.6 (64-bit + Google V8)

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

Hi, can you make a simplified phpunit test case?

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.

Thanks, I see it is the same issue in MODM-66. We'll have a look and see what is wrong. Thanks, Jon

Test Case Added

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

Fantastic! it works. Many many thanks

I can also say that it works. This should be resolved.

When it is added into the master branch?

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!

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

Ubuntu, PHP 5.3.2, Mongo 1.6.3

The covering test and fix can be found here: http://github.com/weaverryan/mongodb-odm/tree/embedded_document_changeset_problem

Fixed here - http://github.com/doctrine/mongodb-odm/commit/01e02406f37a316399f4161d00b72efe43716173

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)

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

I use this update, now i cant delete childrens with a other embedded 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:

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

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

I have create a new issue: MODM-89

Multiplatform

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?

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.

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

Mac osx

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.

CentOS 5.5, PHP 5.3.3

You would just do this:

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

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.

Ubunuto, Zend Server, MongoDB 1.6.3

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

Thanks! Fixed in master.

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

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
{
    // ...
}

PHP 5.3.1, Doctrine ODM MongoDB 2010-06-22 16:07:10

It is just not implemented/finished yet. I will fix the code you mention soon. Thanks, Jon

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

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?

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?

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

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?

Can you make a test then with how your entities are setup so I can work on a patch?

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.

I'm pretty certain this is fixed now. I ran your test and it is passing now. I merged the changes and committed it.

ubuntu, php 5.3.2, odm 1.0.0ALPHA1

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.

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

this should be resolved in the current trunk

all the magic was removed

Dropped MappedSuperClasses and switched to Document classes.

I'm not very happy to have abstract classes configured as Document, but it works.

Hi, can you make a test case for this exposing the problem?

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.