Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-dev] Re: bug 309681 - coarsly analyze skipped WDF tests

Hi Adrian,

I'm not sure if you have set up a wiki or some other area for discussion yet, so I'll reply by email. We can definitely have a discussion when you are in Ottawa for the EclipseLink summit. For the issues we agree are bugs on enhancements, we should likely file separate bugs and reference them from this bug.

Here are some comments from a fairly quick look at your patch. Please feel free to let me know if I have misunderstood anything.

---

- testRelationshipToRemoved: Employee has a relationship to Cubicle, which has
been removed (not yet flushed). This should be rejected with
IllegalStateException according to JPA1: 3.2.3.

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

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.

---

-testChangedEntityIgnoredByFlush: A flush before a query flushes an entity not
queried for. This could be surpressed.

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

---

-testPersistRemovedEntityWithIdModifiedInPrePersistFlushed, testPersistRemovedEntityWithIdModifiedInPrePersist

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

---

- testNastyTimestampTwice: non-entity subclass of entity cannot be persisted

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?

---

- org.eclipse.persistence.testing.tests.wdf.jpa1.entitymanager.TestReadOnly:
methods testIllegalFieldModification, testQueryCachedEntity and
testCacheQueriedEntity fail with a NPE. It turns out that an entity annotated
with @ReadOnly is not inserted at all.

Possibly a spec interpretation issue?

---

- testRefreshManagedNew: we assume that refresh transits a "managed_new" entity
to managed state -> duprec

duprec?

---

- testRefreshManagedCheckContains:
  if a refresh fails with an EntityNotFoundException, the entity is still
contained in the PC. Issue?

seems like a potential issue to me

---

-org.eclipse.persistence.testing.tests.wdf.jpa1.entitymanager.TestRemove.testRemoveFlushRemoveAgain:
- SAP JPA has special state DELETED_EXECUTED, which EclipseLink hasn't

Lets discuss this

---

- org.eclipse.persistence.testing.tests.wdf.jpa1.lock.TestLockMethod
- testLockOldVersion: RollbackExcetpion with cause OLE is thrown; OLE does not
contain causing entity (optional)

Seems like we should investigate including the causing entity

---

- testIllegalVersionAccessNew: manual changing the version is not detected

This is not something EclipseLink typically does, but is worth discussing

---

- testNode: strange exception: "Null primary key encountered in unit of work
clone "; test looks OK

Needs investigating

---

org.eclipse.persistence.testing.tests.wdf.jpa1.relation.TestRelationshipsWithCache
- methods testCostCenterEmployee, testMotorVehicleEmployee,
testCubicleEmployee, testBicycleEmployee, testEmployeeProject: Cached entities
not contained after find. Issue with complicated graph containing non-cachable
entities?

Needs investigating

---

org.eclipse.persistence.testing.tests.wdf.jpa1.simple.TestBasicPropertyTypes

Some of these issues likely require fixes. We have a persistence unit property called "eclipselink.allow-zero-id" that may affect the behavior here

-Tom

Goerler, Adrian wrote:
Hi Tom, Michael, others,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=309681 in the WDF test suite, we are still having a large number (~200) of test, which are skipped with @ToBeInvestigated. These are basically all tests, which would have failed upon the initial check in of the test suite. So far, we have not systematically analyzed these tests and know only very few details. In order to get a better understanding of these skipped tests, we are currently doing a quick run over the issues to get a rough idea of their causes. Hopefully, this allows us to classify whether an issue is caused by
    * Different interpretation of the JPA spec
    * Exotic test model
    * Bug in EclipseLink
    * Bug in the test
    * Whatsoever

Coming to Ottawa in may, we’d like to take the chance to discuss selected issues with the team. So far, I am keeping track of the results of the investigation in the bugzilla ticket 309681. I am not sure that this is a good idea as the ticket will get quite lengthy. Maybe a Wikipedia page would be better? Or an Excel? What do you think? En passant, I have fixed some obvious issues with the test and the framework, which I would like to check in. Please find a patch in the bugzilla ticket. Tested SE on MySQL and Oracle and EE on JBoss / MySQL. Could you please have a look? -Adrian *Adrian Görler
**SAP AG

*Pflichtangaben/Mandatory Disclosure Statements: _http://www.sap.com/company/legal/impressum.epx_


Back to the top