[UOW] Only get change set from documentChangeSets if it exists.

[rjelierse]

This prevents notices of Undefined index: 0000000062aacd13000000000d79d12e in documents that use CHANGETRACKING_NOTIFY and for some reason do not have an entry in UnitOfWork::documentChangeSets.

[jwage]

I am not sure if this is a proper fix. We should probably identify why the index is not set instead of silencing it.

[rjelierse]

You're probably right. After a day of stepping through my tests using XDebug I was unable to identify the cullprit. I can try to set up a test suite that mimics my situation?

[jwage]

That would be great.

[malarzm]

@rjelierse I know some time has passed but any news on test suite? :)

[malarzm]

Closing the issue for now, if anyone would have more information on it please reopen

[rbrtbn]

I also ran into this problem and it happens when you flush a single (managed) document for the second time without property changes since the first flush and the document uses the NOTIFY change tracking policy. After the first flush the UnitOfWork::$documentChangeSets is cleared (at the end of the UnitOfWork::commit() method) and when you try to flush for the second time (without changing any properties on the document) than this notice gets thrown. If you use a different change tracking policy everything works fine in this scenario, so this should too.

@jwage The required index (the oid of the document) on the UnitOfWork::$documentChangeSets property doesn't get set because no one calls the UnitOfWork::propertyChanged() method on the flushed document beforehand. That's what creates the index and I think it is perfectly acceptable, if you don't call this method between two flushes and you should only get an empty change set during the second flush doing so. So I think this is the proper fix for this problem.

What should be done to reopen and accept this pull request?

[malarzm]

@banrobert it seems like you've nailed the problem, best thing to do is create PR with test case (and this fix included if it indeed solves the problem) :)

[rbrtbn]

OK, I'll create a new PR next week with a test case.
I also found an other problem with the UnitOfWork::commit() method when using the NOTIFY change tracking policy (it clears the whole UnitOfWork::$documentChangeSets when flushing only one document and by this all the subsequent flushes become useless). I'll also include the fix for that in the PR as these two problems seem to be connected to each other. I'll write a test case for this too.