Hi Markus,
I checked with Linda, and she confirmed that the current spec requires
non-entities to cause an exception on EM operations as well as cascade
operations, as from the spec perspective, cascade means applying EM
api logic to the related instance. She plans to clarify this.
She is also interested in real user cases when the opposite behavior
is needed, so if you know any, please let her know.
thanks,
-marina
Markus Fuchs wrote On 09/26/06 09:18,:
> 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.
>>