Reorganize read-only class check in UnitOfWork

[rvanlaak]

Right now, calling computeChangeSets and thereafter trying to rely on isReadOnly does not work as expected. The state of readOnlyObjects internally did not sufficiently get updated. Thereby public method isReadOnly is not as reliable as expected.

This PR moves the check for read-only classes to a different location in the code to improve reliability of isReadOnly.

Taking the metadata to userland in order to check for a class to be readonly is not preferable, especially as computeChangeSets already is iterating over the metadata and entity objects.

Expected behavior

Being able to reliably use isReadOnly to throw an exception in userland when a write to an entity is expected while these values won't be committed / flushed by the orm.

[mpdude]

@beberlei Maybe you can advise about the meaning of "readonly" here?

Potential confusion: An entity class can be set as readonly; yet, new entity instances that have been passed to EM::persist() will be written on the next flush().

So, shall UnitOfWork::isReadOnly($object) indicate whether a) the given entity is of a readonly class, or b) the entity instance as it is currently being tracked in the identity map is not going to be written to the DB, because it is either a readonly class and has already been persisted or has been loaded as readonly (#7936)?

[github-actions]

There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.
If you want to continue working on it, please leave a comment.

[rvanlaak]

Curious to hear what @beberlei thinks, as it would be helpful being able to reliably ask the UoW whether a class actually is readonly.