Doctrine 2 - ORM

Cached resultset do not add Entities in UnitOfWork

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.2
  • Component/s: None
  • Security Level: All
  • Labels:
    None

Description

When using resultset cache, when you fetch for these object and attempt to manipulate them, they fail to work giving this message:

Notice:  Undefined index: 000000006f95482300000000384dffac in /srv/app/library/Doctrine/ORM/UnitOfWork.php on line 1901

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. DDC-217 Result cache should cache the SQL result and not the final objects

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Roman S. Borschel added a comment -

Objects coming from the result cache are all detached. The EM does not care about them unless you merge() them. But there should probably be a better exception instead of this notice. Please show the code that causes the notice.

PS: Result caching objects is inefficient.

Show
Roman S. Borschel added a comment - Objects coming from the result cache are all detached. The EM does not care about them unless you merge() them. But there should probably be a better exception instead of this notice. Please show the code that causes the notice. PS: Result caching objects is inefficient.
Hide
Permalink
Guilherme Blanco added a comment -

Test case attached.

This is a situation where it should work smoothly IMHO.

Show
Guilherme Blanco added a comment - Test case attached. This is a situation where it should work smoothly IMHO.
Hide
Permalink
Roman S. Borschel added a comment -

No, it should not work smoothly because $user is a detached object. It should throw an exception but the problem is that its hard to detect whether an object is detached in _doPersist.

Show
Roman S. Borschel added a comment - No, it should not work smoothly because $user is a detached object. It should throw an exception but the problem is that its hard to detect whether an object is detached in _doPersist.
Hide
Permalink
Roman S. Borschel added a comment -

You need to understand the difference between managed and detached. Its very important.

Show
Roman S. Borschel added a comment - You need to understand the difference between managed and detached. Its very important.
Hide
Permalink
Guilherme Blanco added a comment -

Adding merge doesn't work too.... same error.

Juyst add $this->_em->merge($user); in line 52.

Show
Guilherme Blanco added a comment - Adding merge doesn't work too.... same error. Juyst add $this->_em->merge($user); in line 52.
Hide
Permalink
Roman S. Borschel added a comment -

Of course it wouldnt because thats not how merge works. Merge returns a managed copy.

So you would do:

$managedUser = $this->_em->merge($user);

...

$article->setUser($managedUser);

...
Show
Roman S. Borschel added a comment - Of course it wouldnt because thats not how merge works. Merge returns a managed copy. So you would do: $managedUser = $ this ->_em->merge($user); ... $article->setUser($managedUser); ...
Hide
Permalink
Roman S. Borschel added a comment -

http://www.doctrine-project.org/documentation/manual/2_0/en/working-with-objects:merging-entities

Show
Roman S. Borschel added a comment - http://www.doctrine-project.org/documentation/manual/2_0/en/working-with-objects:merging-entities
Hide
Permalink
Benjamin Eberlei added a comment -

Implemented through DDC-217

Show
Benjamin Eberlei added a comment - Implemented through DDC-217

People

  • Assignee:
    Roman S. Borschel
    Reporter:
    Guilherme Blanco
Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: