EAGER not the default fetch type without the @Basic annotation

• Key: OPENJPA-281
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Kevin Sutter
• Reporter: Kevin Sutter
• Component/s: jpa
• Affects Version/s: 0.9.7
• Fix Version/s: 1.0.0

Description

There's an on-going discussion on the dev mailing list concerning this problem (http://www.nabble.com/Eager-fetching-not-working-with-enums-and-lobs-tf4037105.html). Since I've gotten agreement on at least one aspect of the problem, I decided to open this JIRA Issue to document the problem.

Here's a summary of the problem:

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;

The JPA spec attempts to address this situation in section 9.1.18... 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?

We're still working on the agreement... :-)

Thanks,
Kevin

Comments

[Kevin Sutter]

After a bit more discussion on the mail thread, I decided to ping Mike Keith (co-lead of the JPA spec) on his interpretation of the 9.1.18 and 2.1.6 sections of the spec. Here's his response:

"You are correct. Lobs are to be treated like other Basic attributes and should default to EAGER. Your colleague is somewhat justified in that lobs can be costly to load, however, once we put lobs under the category of basic mappings we needed to be consistent and have them use the same defaults. If they are expected to be both large and not referenced often then @Basic(fetch=LAZY) should be used. Note that if one of these is not true then you probably do want them to be eagerly loaded.

-Mike"

That should decide it. This Issue will be used to change the behavior be consistent with the @Basic annotation and make all listed types as EAGER fetch type by default.

[Kevin Sutter]

I decided to post a patch for this Issue before committing it in order to get feedback first... Take a look at FieldMetaData and see how I am determining whether to include a given type in the default fetch group. Although it looks a little strange to be doing all of this testing for Serializable, Enums, and Lobs, it actually limited the changes to this single part. Other alternatives started to ripple through out the code base and I didn't see where it was buying anything. If I don't hear anything negative, I'll commit these changes later today.

I also updated AllFieldTypes and created a new TestBasicAnnotation testcase so that we don't accidentally re-introduce this problem.

The other change to FieldMapping.java was to avoid an obscure NPE when parsing some orm.xml.

Thanks,
Kevin

[Kevin Sutter]

I just committed the changes posted in my patch from last week. No additional comments were received, so I am taking that as general agreement.

Just a bit more historical background on these changes in case we have to revisit this in the future. My first thought on making Eager work for Enums was to introduce a new ENUM type code in org.apache.openjpa.meta.JavaTypes. Although this change started off simple and elegant, it quickly rippled to many more changes through out the code that really didn't add any value. So, I decided to just test for Enums in FieldMetaData instead. This change was isolated and didn't have the ripple effect.

On the chance that we need more specialized processing for the Enum type, then we might have to revert to my original thought. But, for this immediate problem, a new type code seemed like overkill.

Kevin

Resolved via revision 562986.