Associative references cannot be read #515

Closed
Bilge opened this Issue Feb 27, 2013 · 21 comments

Comments

Projects
None yet
4 participants
@Bilge
Contributor

Bilge commented Feb 27, 2013

With strategy="pushAll", a @ReferenceMany will only store array_values($array). However, with strategy="set" it is possible to store associative arrays. However, despite being stored correctly, Doctrine cannot fetch associative array references, instead throwing the following errors.

Warning: Illegal offset type in mongodb-odm/lib/Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php on line 665

Notice: Array to string conversion in mongodb-odm/lib/Doctrine/ODM/MongoDB/DocumentNotFoundException.php on line 33

exception 'Doctrine\ODM\MongoDB\DocumentNotFoundException' with message 'The "Example" document with identifier "Array" could not be found.' in mongodb-odm/lib/Doctrine/ODM/MongoDB/DocumentNotFoundException.php:33

@eugene-dounar

This comment has been minimized.

Show comment Hide comment
@eugene-dounar

eugene-dounar Oct 4, 2013

Is there any way to handle associative references for now?
How can we approach fixing this issue? Does anyone work on a PR?

Is there any way to handle associative references for now?
How can we approach fixing this issue? Does anyone work on a PR?

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Oct 4, 2013

Contributor

Like most of my old bug reports nobody is working on them :)

Contributor

Bilge commented Oct 4, 2013

Like most of my old bug reports nobody is working on them :)

@jmikola

This comment has been minimized.

Show comment Hide comment
@jmikola

jmikola Oct 16, 2013

Owner

Doctrine cannot fetch associative array references

How were these being fetched? Is the field in the MongoDB document is stored as an associative array (BSON object), it should still be hydrated as a PersistentCollection on the way out of MongoDB, and the associative keys should be accessible. Do you have a snippet of code to reproduce the exception? I can turn it into a test case if necessary.

Owner

jmikola commented Oct 16, 2013

Doctrine cannot fetch associative array references

How were these being fetched? Is the field in the MongoDB document is stored as an associative array (BSON object), it should still be hydrated as a PersistentCollection on the way out of MongoDB, and the associative keys should be accessible. Do you have a snippet of code to reproduce the exception? I can turn it into a test case if necessary.

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Nov 4, 2015

Member

Out of curiosity I hacked this test case and it is passing now:

    public function testAssociativeRefMany()
    {
        $d = new Strategy();
        $t = new Task('Task #1');
        $t2 = new Task('Task #2');
        $d->tasks['important'] = $t;
        $d->tasks['todo'] = $t2;
        $this->dm->persist($t);
        $this->dm->persist($t2);
        $this->dm->persist($d);
        $this->dm->flush();
        $this->dm->clear();

        $d = $this->dm->find(get_class($d), $d->id);
        $this->assertCount(2, $d->tasks);
        $this->assertNotNull($d->tasks['important']);
        $this->assertNotNull($d->tasks['todo']);
    }
Member

malarzm commented Nov 4, 2015

Out of curiosity I hacked this test case and it is passing now:

    public function testAssociativeRefMany()
    {
        $d = new Strategy();
        $t = new Task('Task #1');
        $t2 = new Task('Task #2');
        $d->tasks['important'] = $t;
        $d->tasks['todo'] = $t2;
        $this->dm->persist($t);
        $this->dm->persist($t2);
        $this->dm->persist($d);
        $this->dm->flush();
        $this->dm->clear();

        $d = $this->dm->find(get_class($d), $d->id);
        $this->assertCount(2, $d->tasks);
        $this->assertNotNull($d->tasks['important']);
        $this->assertNotNull($d->tasks['todo']);
    }

@malarzm malarzm closed this Nov 4, 2015

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Nov 5, 2015

Contributor

Thanks @malarzm!

Contributor

Bilge commented Nov 5, 2015

Thanks @malarzm!

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Dec 22, 2015

Contributor

Although collections are persisted with named keys (using strategy="set") they are still hydrated with numeric keys.

Contributor

Bilge commented Dec 22, 2015

Although collections are persisted with named keys (using strategy="set") they are still hydrated with numeric keys.

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Dec 22, 2015

Member

@Bilge has my test started failing or have I missed something in it?

Member

malarzm commented Dec 22, 2015

@Bilge has my test started failing or have I missed something in it?

@malarzm malarzm reopened this Dec 22, 2015

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Dec 23, 2015

Contributor

@malarzm Grepping for your test does not seem to return any results.

Contributor

Bilge commented Dec 23, 2015

@malarzm Grepping for your test does not seem to return any results.

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Dec 23, 2015

Contributor

@malarzm The error is my own. I was retrieving the wrong record when I did the hydration! Indeed, it does seem to work now, however your test is still missing or I simply cannot find it.

Contributor

Bilge commented Dec 23, 2015

@malarzm The error is my own. I was retrieving the wrong record when I did the hydration! Indeed, it does seem to work now, however your test is still missing or I simply cannot find it.

@Bilge Bilge closed this Dec 23, 2015

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Dec 23, 2015

Member

Oh, I just posted it as a comment above (#515 (comment)) as at the moment both reference many and embed many are handled in the same way (both lists and maps) and I can't see these two diverging anyhow and for associative embeds we have tests :)

Member

malarzm commented Dec 23, 2015

Oh, I just posted it as a comment above (#515 (comment)) as at the moment both reference many and embed many are handled in the same way (both lists and maps) and I can't see these two diverging anyhow and for associative embeds we have tests :)

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Dec 23, 2015

Contributor

As long as there is a test case for this somewhere all is well! 👍 However, as an aside, you cannot expect me to run the test in your comment since I do not have access to all of its dependencies, i.e. Strategy and Task!

Contributor

Bilge commented Dec 23, 2015

As long as there is a test case for this somewhere all is well! 👍 However, as an aside, you cannot expect me to run the test in your comment since I do not have access to all of its dependencies, i.e. Strategy and Task!

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Dec 23, 2015

Member

I do not have access to all of its dependencies, i.e. Strategy and Task!

Right, I could have pasted whole test case, however if you'd take a look into ODM tests themselves you'll easily spot these two beings living in the Documents namespace ;)

Member

malarzm commented Dec 23, 2015

I do not have access to all of its dependencies, i.e. Strategy and Task!

Right, I could have pasted whole test case, however if you'd take a look into ODM tests themselves you'll easily spot these two beings living in the Documents namespace ;)

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Jan 14, 2016

Contributor

Although persist and retrieve works correctly the first time, I find am finding that updates to associations annotated like @EmbedMany(targetDocument="Foo", strategy="set") are not detected by Doctrine, thus leaving it perpetually in the state of the first write.

In my particular case, I have this relationship type (embedded document using set strategy) nested two levels deep, but I'm not sure if that makes a difference or not.

Contributor

Bilge commented Jan 14, 2016

Although persist and retrieve works correctly the first time, I find am finding that updates to associations annotated like @EmbedMany(targetDocument="Foo", strategy="set") are not detected by Doctrine, thus leaving it perpetually in the state of the first write.

In my particular case, I have this relationship type (embedded document using set strategy) nested two levels deep, but I'm not sure if that makes a difference or not.

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Jan 14, 2016

Member

@Bilge could you put together failing test case and submit as a PR?

Member

malarzm commented Jan 14, 2016

@Bilge could you put together failing test case and submit as a PR?

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Jan 14, 2016

Contributor

@malarzm No, I don't think so. I don't know how to write ODM tests, but I'd be happy to help someone who does.

Contributor

Bilge commented Jan 14, 2016

@malarzm No, I don't think so. I don't know how to write ODM tests, but I'd be happy to help someone who does.

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Jan 14, 2016

Member
@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Jan 14, 2016

Contributor

You say it's not very hard, but that is from your perspective, as someone who has a good grasp of how Doctrine works even internally. I am not very good at PHP codes :^)

Contributor

Bilge commented Jan 14, 2016

You say it's not very hard, but that is from your perspective, as someone who has a good grasp of how Doctrine works even internally. I am not very good at PHP codes :^)

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Jan 14, 2016

Member

I'm just trying to motivate you, you just need to do what your app is doing in isolation ;)

I have this relationship type (embedded document using set strategy) nested two levels deep, but I'm not sure if that makes a difference or not.

So you have something like: document -> collection_1 -> collection_2 and if you change something in collection_2 then it's not saved?

Member

malarzm commented Jan 14, 2016

I'm just trying to motivate you, you just need to do what your app is doing in isolation ;)

I have this relationship type (embedded document using set strategy) nested two levels deep, but I'm not sure if that makes a difference or not.

So you have something like: document -> collection_1 -> collection_2 and if you change something in collection_2 then it's not saved?

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Jan 14, 2016

Contributor

@malarzm That's exactly it. 👍 It is saved the first time, but Doctrine appears to be unable to track updates on subsequent persist/flushes of the top-level document.

Perhaps a new issue should be created to track this since it has diverged somewhat from the original report.

Contributor

Bilge commented Jan 14, 2016

@malarzm That's exactly it. 👍 It is saved the first time, but Doctrine appears to be unable to track updates on subsequent persist/flushes of the top-level document.

Perhaps a new issue should be created to track this since it has diverged somewhat from the original report.

@malarzm

This comment has been minimized.

Show comment Hide comment
@malarzm

malarzm Jan 14, 2016

Member

Oh, subsequent flushes sounds interesting. Could you open new issue?

Member

malarzm commented Jan 14, 2016

Oh, subsequent flushes sounds interesting. Could you open new issue?

@Bilge

This comment has been minimized.

Show comment Hide comment
@Bilge

Bilge Jan 14, 2016

Contributor

I think our discussion elsewhere concluded that flushing the object manager was the source of all woes on this occasion, therefore an issue should not need to be created after all, as we may assume that feature still works correctly under normal circumstances.

Contributor

Bilge commented Jan 14, 2016

I think our discussion elsewhere concluded that flushing the object manager was the source of all woes on this occasion, therefore an issue should not need to be created after all, as we may assume that feature still works correctly under normal circumstances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment