Hello Markus,
I have closed bug 1035 but I do not believe it is a duplicate of issue 1021. 1021 is a reported error case that should be fixed.
--Gordon
-----Original Message-----
From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of Markus Fuchs
Sent: Wednesday, September 27, 2006 1:23 PM
To: persistence_at_glassfish.dev.java.net
Subject: Re: Fix for issue 1021
Hi Gordon,
Issue 1035 looks like a duplicate of 1021 to me. Would you mind marking it as such?
Thank,
-- markus.
Wonseok Kim wrote:
Isn't it a duplicate of issue 1035?
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1035
- Wonseok
On 9/27/06, Markus Fuchs <Markus.Fuchs_at_sun.com> wrote:
Hi Gordon,
Reading section 2.1.9.3 I only find that non-entity super classes can't be persistent:
The non-entity superclass serves for inheritance of behavior only. The state of a non-entity superclass is
not persistent. Any state inherited from non-entity super classes is non-persistent in an inheriting entity
class. This non-persistent state is not managed by the EntityManager[12]. Any annotations on such
super classes are ignored.
This doesn't say anything about non-entity subclasses of entity classes. Further on, the next sentence:
Non-entity classes cannot be passed as arguments to methods of the EntityManager or Query
interfaces and cannot bear mapping information.
Says that non-entity classes can't be persisted, etc. Even if not explicitly stated, it would only make sense to apply the above rule to cascaded operations. The situation described in 1021 shows an example, where cascading the persist operation to a non-entity subclass doesn't work in the current implementation.
Thanks,
-- markus.
Gordon Yorke wrote:
Hello Markus,
I am a little confused here. There was already a discussion about this behaviour and I believe the conclusion was to allow users to reference non-entity inheritance heirarchy members in their object model. TopLink would persist the state from the parent Entity object. (discussion thread had subject : "How to prevent stack overflow" and was in reference to gf bug 939).
Contrary to the comments in the bug there is nothing the specification that prevents this behaviour and the specification even covers this case in section 2.1.9.3
If we are not validating EntityManager and Query apis then that needs to be added but this bug is not a validation issue.
--Gordon
-----Original Message-----
From: Markus.Fuchs_at_Sun.COM [ mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of Markus Fuchs
Sent: Monday, September 25, 2006 8:08 PM
To: persistence_at_glassfish.dev.java.net
Subject: Fix for issue 1021
Hi TopLink team,
I'm trying to fix issue 1021: VALIDATION: Disallow persisting non-entity subclasses
Can I assume that there's a one-to-one relationship btw. entity classes
and descriptors? I.e. is the follow statement true:
Class is annotated as @Entity <=> There's a ClassDescriptor for that class.
Based on this assumption, the attached change throws a RuntimeException in
AbstractSession.getDescriptor(Class theClass), if the descriptor for a class
is not found. Adding it there will also change TopLink behavior for the
non-JPA case. The exception message must still be localized, of course.
Is there any reason, why TopLink returns the superclass descriptor, if no
descriptor for the a class can be found?
Another place to add this validation would be in EntityManagerImpl,
similar to how em.contains() is called for some JPA operations. But
that would not cover the cases were the operation is cascaded to an
instance, as the internal operation is called directly and not through
the EM interface.
I tested the validation by trying to persist a non-entity class or a
mapped superclass instance.
What do you think?
Thanks!
-- markus.