lazy fetch seems doesn't work

[springsource_roo]

I have code below, and mark content as lazy load. The purpose is that when building list of document, hibernate will not load content column.

But during observe SQL, I found hibernate always load "content" column when building list of document? Is it a bug or my understanding is incorrect.



@RooJavaBean
@RooToString
@RooEntity
public class Document {

private static final Log log = LogFactory.getLog(Document.class);

@NotNull
@Size(max = 30)
private java.lang.String name;

@NotNull
@Size(max = 500)
private java.lang.String description;

private java.lang.String filename;

@NotNull
@Lob
@Basic(fetch = FetchType.LAZY)
private byte[] content;

private java.lang.String contentType;

private java.lang.Long size;

@Transient
@Size(max = 100)
private String url ;
}

[krimple]

Read this and specifically the answer below:

http://stackoverflow.com/questions/2...b-lazy-loading

Seems like it isn't supported on all databases.

Out of curiosity, what datatype is it mapped to on the database side and what database are you using? You aren't specifying a size so I assume that the table is already created? Could we see the schema?

I don't know what your code looks like... Perhaps it's the @NotNull - are you triggering save or validation in some way? To validate that condition it would have to load the field to check it.

Nice username, BTW

[delgad9]

Thank you. I didn't know that...
BTW the class shown seems extracted from one of my articles. Link here http://viralpatel.net/blogs/2011/02/...-tutorial.html.

I am sure is just a coincidence.


B. & Coincident Roogards
jD

[krimple]

@springsource_roo - what is the code you're using to fetch? Are you doing Document.findAll() or something else?

You could cheat and create a custom finder, something where you manually create an instance of the document in your query, like this:

// create a simple finder to get the syntax, then push in and modify this part:
em.createQuery ("select new qualified.with.package.names.Document(d.only,d.fields,d.that,d.you,d.want,d.instantiated) from Document d where...")....

Then, you can build a constructor with just those fields that gets called by this query. Call this finder instead of the normal Document.findAll() and you should be in business. It should work fine when you are building a list for display on your UI as long as you're not planning to treat it as any more than a POJO, with the caveat that these are only rows to be returned to the UI, and they don't take part (if I recall correctly) in the cache of the Hibernate ORM because they are JPAQL queries with custom returned objects, not fetched by Hibernate itself.

That would be a simpler alternative to what they're suggesting on stackoverflow.com - the one to one mapping. The downside is that you'd need to implement variants for what you need to fetch in certain cases. I'm not sure I like it, but it would be an alternative to explore.