persistence@glassfish.java.net

Re: Fix for issue 1021

From: Wonseok Kim <guruwons_at_gmail.com>
Date: Wed, 27 Sep 2006 17:47:09 +0900

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<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.
>
>