Talk:EclipseLink/Bugs/309681

Discussion

org.eclipse.persistence.testing.tests.wdf.jpa1.entitymanager

TestFlush

testChangedEntityIgnoredByFlush

Tom: I'm not sure this is an error according to the spec, but there is likely an interesting enhancement related to this.

Adrian: This is not mandated by the spec.

testRelationshipToRemoved

Tom: What behavior are you actually seeing? Is the behavior any different when you assign both sides of the relationship? i.e. after emp1.setCubicle(cub1); add cub1.setEmployee(emp1)? At the moment, we expect both sides of bidirectional relationships to be set. It is important for our 2nd level cache. For the most part initial SQL will work without setting both sides, but the behavior after that could become unpredictable. We are considering implementing some behavior to help users that only want to set the owning side of bidirectional relationships, but it is not yet implemented. This is something to watch out for in all your tests.

testRelationshipToRemovedLazy

Tom: This test also does not set both sides of a bidirectional relationship. I'm not sure the change would solve the specific issue in the test, but nonetheless, technically an error in EclipseLink.

TestPersist

testNastyTimestampTwice

Tom: Spec issue, or Enhancement? If you persist a non-Entity subclass of an Entity, what do you expect to get when you read it back?

Adrian: This is a possible enhancement. The spec quite clearly rejects non-entity subclasses (§2.11.3 of JPA 2.0: <quote>Non-entity classes cannot be passed as arguments to methods of the EntityManager or Query interfaces[24] and cannot bear mapping information. Footnote [24] This includes instances of a non-entity class that extends an entity class.</qoute>.) However, there are implementations that use subclass proxies for lazy loading. We had a discussion on this in the EG and these subclass proxies are considered legal although they techincally a non-entity subclass. The test expects to be able to persist a subclass non-entity and to get back the closest superclass, which is an entity.

testPersistRemovedEntityWithIdModifiedInPrePersistFlushed

Tom: It is not clear to me from the description what the expected behavior is and how that is different from the actual behavior.

TestReadOnly

testIllegalFieldModification, testQueryCachedEntity and testCacheQueriedEntity

Tom: Possibly a spec interpretation issue?

Adrian: read only entities are not (yet) covered by the spec. To me this appears to be a bug. Or I don't understand the intended behavior of EclipseLink's @ReadOnly annotation.

TestRefresh

testRefreshManagedCheckContains

Tom: seems like a potential issue to me

testRefreshManagedNew

Tom: duprec?

Adrian: The test does the following:

* begin
* persist an entity (schedules it for INSERT)
* insert the same entity using SQL
* refresh // !!
* commit -> duprec''

The test assumes that the refresh operation detects that the entity already exists on the DB, refeshes its content from the DB and transits the entity's state from "scheduled for insert" to "managed". Basically, the asumption is that the explicit refresh should allow to avoid the duprec.