Ok, I don't like it either. Craig
On Jul 9, 2007, at 9:34 AM, Patrick Linskey wrote:
Hi, I think that 2.1.6 makes the behavior relatively clear: "If the type of the field or property is one of the following, it is mapped in the same way as it would if it were annotated as Basic:" That definitely implies that a field with no annotation should be mapped as if the Basic annotation were present. However, I still don't like it. -Patrick On 7/9/07, Craig L Russell <[EMAIL PROTECTED]> wrote: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 RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 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!
smime.p7s
Description: S/MIME cryptographic signature
