[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4358?page=c...
]
Karsten Wutzke edited comment on HHH-4358 at 12/19/11 4:47 PM:
---------------------------------------------------------------
Here's what Michael Keith (Author of Pro JPA 2 and member of the JPA expert group) had
to say about this:
"The spec does not require an implementation to use discriminator columns to
implement JOINED inheritance, however, the assumption is that if @DiscriminatorColumn is
specified then it would be used, i.e. the values would be written out. We do not
explicitly state that if a @DiscriminatorColumn is specified in the code it must be used,
just like we don't explicitly state that if a @Column or @JoinColumn is specified the
values must be stored in the table, but there is only so much that we can or should
specify. At the lowest level, certain laws of physics and reason are just assumed."
So implementing an option would be the way to go (even though I still believe Hibernate is
wrong). I wonder how existing applications would break if they set the correct
discriminator value instead of the wrong one now... (sorry for turning this into a
discussion)
was (Author: kwutzke):
Here's what Michael Keith (Author of Pro JPA 2 and member of the JPA expert group)
had to say about this:
"The spec does not require an implementation to use discriminator columns to
implement JOINED inheritance, however, the assumption is that if @DiscriminatorColumn is
specified then it would be used, i.e. the values would be written out. We do not
explicitly state that if a @DiscriminatorColumn is specified in the code it must be used,
just like we don't explicitly state that if a @Column or @JoinColumn is specified the
values must be stored in the table, but there is only so much that we can or should
specify. At the lowest level, certain laws of physics and reason are just assumed."
So implementing an option would be the way to go (even though I still believe Hibernate is
wrong nontheless). I wonder how existing applications would break if they now set the
correct discriminator value instead of the wrong one now... (sorry for turning this into a
discussion)
Having to use @ForceDiscriminator kind of breaks JPA compatibility
------------------------------------------------------------------
Key: HHH-4358
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4358
Project: Hibernate Core
Issue Type: Improvement
Components: annotations
Environment: JPA
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Labels: jpa2
Fix For: 4.0.1
According to
http://opensource.atlassian.com/projects/hibernate/browse/ANN-36
@ForceDiscriminator was created as a quick workaround to a problem.
Yes, it solves the problem, but it creates a new problem:
the source code which previously had only JPA annotations, now need to be annotated by a
Hibernate annotation,
causing that the the source code is now unable to use just any JPA provider.
Major portability issue!
Everyone who likes Open Source, hates Lock-Ins!
My proposal: change the default to a more sane force=true, so that @ForceDiscriminator
will not be needed for general JPA projects.
(And create a @DisableDiscriminator Hibernate annotation, for those who like to brake
their code).
If changing default behavior is risky, don't fix this on older versions, but lets
change this from 3.5.0-Beta2.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira