Hi Michael, Tom,
Thanks for the feedback.
I have submitted the patch attached to this ticked (reviewed by Michael).
Your suggestion to rather have a parent bug with many small child bugs sounds very convincing. An accompanying Wiki-page as suggested by Michael makes a lot of sense to me as well.
Likely there are many small issues, which aren’t really bugs but just require a short discussion to clarify the expected behavior of EclipseLink. I am a bit unsure whether such small corner cases would be worth a separate bug.
--- Begin Message ---
- From: Tom Ware <tom.ware@xxxxxxxxxx>
- Date: Wed, 28 Apr 2010 16:19:49 +0200
- Thread-index: Acrm3hIS6ksthv4gQMGxtsAJwFv6tQ==
- Thread-topic: bug 309681 - coarsly analyze skipped WDF tests
- User-agent: Thunderbird 126.96.36.199 (Windows/20100228)
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.
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.
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?
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
if a refresh fails with an EntityNotFoundException, the entity is still
contained in the PC. Issue?
seems like a potential issue to me
- SAP JPA has special state DELETED_EXECUTED, which EclipseLink hasn't
Lets discuss this
- 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
- methods testCostCenterEmployee, testMotorVehicleEmployee,
testCubicleEmployee, testBicycleEmployee, testEmployeeProject: Cached entities
not contained after find. Issue with complicated graph containing non-cachable
Some of these issues likely require fixes. We have a persistence unit property
called "eclipselink.allow-zero-id" that may affect the behavior here
Goerler, Adrian wrote:
> Hi Tom, Michael, others,
> 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 Görler
> **SAP AG
> *Pflichtangaben/Mandatory Disclosure Statements:
--- End Message ---