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