As I've already said, the spec is pretty opaque. Before assuming that a missing @Basic annotation still has a default fetch=EAGER element, I'd want to see a spec clarification. Clearly there is no TCK test possible for this...

Craig

On Jul 9, 2007, at 9:17 AM, Kevin Sutter wrote:

:-) The only reason why I would want to eagerly fetch LOBs is to satisfy the intent of the spec. Since the @Basic annotation is optional and the default fetchType is EAGER, then I assert that the spec indicates that LOBs
need to be fetched EAGERly.  Do you read the spec differently?

I will agree that "in practice" LOBs should not be fetched EAGERly. But, we need to be consistent with the spec so as not to surprise customers as they
move from one JPA implementation to another.

Kevin

On 7/9/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:

Indeed you do... why would we want to eagerly fetch LOBs? I understand
the logic if @Basic is specified, but not if it is omitted.

-Patrick

On 7/9/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:
> I have opened JIRA Issue 281 (
> https://issues.apache.org/jira/browse/OPENJPA-281) for this problem. It > seems that we have agreed that enums should be EAGER by default. I just
> have to convince everybody that lobs also have to be EAGER, by
default...
> :-)
>
> Thanks,
> Kevin
>
> On 7/8/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:
> >
> > 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!
> > >
> > >
> > >
> >
>


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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to