You are not the only one, but unfortunately the uncoordinated works of some
JSRs catering to upcoming Java releases are getting you exactly that, and
let's say you need compile-time safety, BeanValidation (probably in a wider
context with other parts like JSF) and some influence on the generated
query you may just end up with 3 or more of these in your code[?]
On Tue, Aug 28, 2012 at 4:52 PM, Oliver Gierke <ogierke_at_vmware.com> wrote:
> Sounds good. To be honest, I didn't quite get the connection. And on
>
> > @OneToOne(nullable = true) @NotNull @NonNull @Nullable(true) Address
> address;
>
> it threw me out of the corner eventually :)
>
> Cheers,
> Ollie
>
> Am 28.08.2012 um 16:29 schrieb Werner Keil <werner.keil_at_gmail.com>:
>
> > Thanks for correcting that.
> >
> > If it wasn't for the typo, you probably wouldn't have inspired me to
> highlight the "nullable" issues. Maybe should go into separate thread to
> ensure better visibility?
> >
> > Werner
> >
> > On Tue, Aug 28, 2012 at 4:27 PM, Oliver Gierke <ogierke_at_vmware.com>
> wrote:
> > Hi all,
> >
> > sorry for that glitch. I essentially meant the "optional" attribute. So
> the sample could should have read:
> >
> > @Entity
> > class Person {
> >
> > @OneToOne(optional = true) Address address;
> > }
> >
> > @Entity
> > class Address {
> > String city;
> > }
> >
> > Note that for the …ToOne annotation the optional flag defaults to true,
> so unless you're explicitly changing this to false (and thus change the
> semantics of the modeling completely) you're likely to run into the
> situation described.
> >
> > Cheers,
> > Ollie
> >
> > Am 28.08.2012 um 15:12 schrieb Werner Keil <werner.keil_at_gmail.com>:
> >
> > > Oliver/all,
> > >
> > > Thanks for pointing that out.
> > > While the actual query may not be changed, you can sure contradict the
> nullable = true by adding a @NotNull annotation from Bean Validation to it.
> The two are legitimate together:
> http://stackoverflow.com/questions/2725111/hibernate-onetoone-notnull
> > >
> > > Java 7 and EE7 most likely give you a Runtime Exception, maybe some
> IDE warning if it provides JPA support, but the compiler itself is not
> going to do much about it.
> > >
> > > JSR 308, so far scheduled for Java 8 aims to change that:
> > > http://types.cs.washington.edu/jsr308/
> > >
> > > Unfortunately, both the Spec Leads of 308 deny any responsibility or
> ownership of checker annotations, nor have the architects at Oracle so far
> take precautions to avoid a big mess like this
> > >
> > > @Entity
> > > class Person {
> > >
> > > @OneToOne(nullable = true) @NotNull @NonNull @Nullable(true) Address
> address;
> > > }
> > >
> > > BeanValidation as of now
> > > Checker Annotations based on JSR 308 as of now (from Java 8)
> > >
> > > Given a combination of Java EE 6/7 and JSR 308 this would be perfectly
> fine. Most likely the two checkers would cause a compiler error already,
> but one alone, let's say @Nullable(true) instead of a sensible integration
> with all existing stuff will increase the big mess around these annotations
> already present
> > >
> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
> > >
> > > I probably forgot @Nonnull as of JSR 305 which at the moment polutes
> the JDK already, but has no effect. At the very least, instead of having
> people stuff in more annotations of all different kinds, either @Nonnull
> should be killed with Java 8 and replaced with something else, or it should
> be used. Most likely the conflict with BeanValidation (which is primarily
> used by JPA) would be unavoidable then.
> > >
> > > Sorry to hijack the thread, I hope, at least Linda keeps an eye on
> that or plans to do something about it, so that we can avoid annotation
> chaos we inherited in other areas, e.g. @Inject vs. other legacy
> approaches, etc.?
> > >
> > > Thanks,
> > > Werner
> > >
> > > On Tue, Aug 28, 2012 at 2:44 PM, Oliver Gierke <ogierke_at_vmware.com>
> wrote:
> > > Hi all,
> > >
> > > I just came across a JPQL spec scenario that seems to be a bit weird
> and I wonder whether there's something we should do about. Suppose you have
> a Person with optional Addresses:
> > >
> > > @Entity
> > > class Person {
> > >
> > > @OneToOne(nullable = true) Address address;
> > > }
> > >
> > > @Entity
> > > class Address {
> > > String city;
> > > }
> > >
> > > Now the query scenario here is that we'd like to get all Persons
> sorted by the Address' city:
> > >
> > > select p from Person p left outer join p.address order by
> p.address.city
> > >
> > > Surprisingly, this query will not return Persons not having an Address
> associated for the following reason: JPA 2.0 spec section 4.4.4. defines
> path expressions as follows:
> > >
> > > > Path expression navigability is composed using “inner join”
> semantics. That is,
> > > > if the value of a non-terminal field in the path expression is null,
> the path is
> > > > considered to have no value, and does not participate in the
> determination of
> > > > the result.
> > >
> > > That apparently forces persistence providers into adding an additional
> inner join to the query which rules out the Persons without Addresses in
> the first place. I think it's rather unfortunate to have this path
> expression definition applied to order by clauses as users probably don't
> expect adding a sort definition would strengthen the actual query criteria.
> So here are my questions:
> > >
> > > 1. Why was the path expression navigability defined as such in the
> first place and not as considering the mapping metadata (nullable = true ->
> outer join, nullable = false -> inner join). Not saying this is utterly
> wrong, just want to understand the probably available reasons.
> > > 2. Should/can this definition be changed to require consideration of
> the mapping information? The path expression definition is very much
> written with the purpose of defining selection criterias which is what they
> are effectively not used for when used in ORDER BY clauses. The current
> state leaves JPQL in the weird state that adding a sorting criteria affects
> the returned items not only in order but also in which items are returned
> at all, a side-effect which is unpleasant and not easy to grasp.
> > >
> > > Cheers,
> > > Ollie
> > >
> > > --
> > > /**
> > > * @author Oliver Gierke - Senior Member Technical Staff
> > > *
> > > * @param email ogierke_at_vmware.com
> > > * @param phone +49-351-30929001
> > > * @param fax +49-351-418898439
> > > * @param skype einsdreizehn
> > > * @see http://www.olivergierke.de
> > > */
> > >
> > >
> >
> > --
> > /**
> > * @author Oliver Gierke - Senior Member Technical Staff
> > *
> > * @param email ogierke_at_vmware.com
> > * @param phone +49-351-30929001
> > * @param fax +49-351-418898439
> > * @param skype einsdreizehn
> > * @see http://www.olivergierke.de
> > */
> >
> >
>
> --
> /**
> * @author Oliver Gierke - Senior Member Technical Staff
> *
> * @param email ogierke_at_vmware.com
> * @param phone +49-351-30929001
> * @param fax +49-351-418898439
> * @param skype einsdreizehn
> * @see http://www.olivergierke.de
> */
>
>