Craig, Comments below... On 7/7/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
Hi Kevin, If you can figure out what the spec (9.1.18 and 9.1.19) sez, my hat's off to you. What a mudbake this is.
Isn't that just standard order of business with these specs? :-) Part of the issue is the annotation definition. If @Basic is
specified, and the user doesn't explicitly override the fetch type, it appears to our annotation processor as if the user specified EAGER. Even if @Basic is used with @Lob, if lazy is wanted, it has to be explicitly stated.
That's how I read the spec. The first paragraph of 9.1.18 indicates that @Basic can be applied to any those types (enums and lob types included). The default fetchType is EAGER. It also states that @Basic is optional. So, the way I read this is that we should be doing EAGER fetching for all of those listed types unless explicitly told to do otherwise via the LAZY fetchType via an @Basic annotation. Maybe we should discuss @Lob in more detail. It isn't obvious to me
that @Basic can always be used and we might have an option to choose a better default for the fetch behavior if @Basic annotation is omitted.
It seems to me that the spec is clear on the use and expectations of @Basic and the default fetchType of EAGER. Unless there are other spec references that contradict the statements in 9.1.18... Craig
On Jul 6, 2007, at 11:37 AM, Kevin Sutter wrote: > I guess the spec is a bit clearer on this than I first thought. > Section > 9.1.8 of the JPA spec indicates that @Basic is optional and applies > to the > following types: > > "..Java primitive types, wrappers of the primitive types, > java.lang.String, > java.math.BigInteger, > java.math.BigDecimal, java.util.Date, java.util.Calendar, > java.sql.Date, > java.sql.Time, java.sql.Timestamp, byte[], Byte[], char[], Character > [], > enums, and any other type that implements Serializable." > > And, since the default fetch type for @Basic is EAGER, it looks > like we need > to do eager fetching for both @Enumerated and @Lob fields unless > otherwise > overridden by a LAZY fetch type (ie. @Basic(fetch=LAZY)). Agree? > > Kevin > > On 7/6/07, Craig L Russell <[EMAIL PROTECTED]> wrote: >> >> >> On Jul 6, 2007, at 10:52 AM, Patrick Linskey wrote: >> >> > The spec doesn't seem to discuss it, but I think that lazy is a >> pretty >> > good default behavior for @Lob field types -- typically @Lob things >> > are big, so you often don't want them in the default fetch graph. >> >> Enum is different, though. Enum should be eager fetching by default. >> >> Lazy fetching is optional, so we can decide what we want to do. It >> seems that the existence of @Basic should not change our strategy. >> And we should default to lazy fetching for Lob and eager fetching for >> Enum. >> >> Craig >> > >> > -Patrick >> > >> > On 7/6/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: >> >> I am finding that the supposed default action of Eager fetching is >> >> not >> >> happening with @Enumerated and @Lob fields. If I explicitly >> >> specify the >> >> @Basic annotation, then the fields are eagerly fetched. But, >> >> without this >> >> extraneous @Basic, these fields are lazily loaded. This action >> >> does not >> >> seem to be consistent with the spec. Nor, can I find any mention >> >> of this >> >> alternate behavior in our OpenJPA manual. Sounds like a bug to >> >> me. Any >> >> other insights? >> >> >> >> This works (eager loading kicks in): >> >> >> >> @Basic @Enumerated(EnumType.STRING) >> >> private Gender gender; >> >> >> >> This does not work (lazy loading kicks in): >> >> >> >> @Enumerated(EnumType.STRING) >> >> private Gender gender; >> >> >> >> I have also tried to use defaults (without any annotations), >> and lazy >> >> loading still kicks in: >> >> >> >> private Gender gender; >> >> >> >> Thanks, >> >> Kevin >> >> >> > >> > >> > -- >> > Patrick Linskey >> > 202 669 5907 >> >> Craig Russell >> Architect, Sun Java Enterprise System http://java.sun.com/products/ >> jdo >> 408 276-5638 mailto:[EMAIL PROTECTED] >> P.S. A good JDO? O, Gasp! >> >> >> Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
