Hi,

if I have some LAZY values (@Formula) in an entity and the entity become detached, can I somehow load/initilize just this LAZY value?

If I have a @OneToOne or @ManyToOne LAZY relationship, I may load it by just

person.setDepartment(entityManager.find(Department.class, departmentId);

Thanks
Andy

lazy loading means the association or collection objects are loaded only when they are accessed. That is SQL query will hit the database when you access them.

So you can not access the association or collection objects (if they set to load lazily) in detached object.

I am sorry for confusion with terms. I mean: Can I load LAZY non-initialised values (@Formula especially) in detached objects? I mean some general solution, not coding a special DAO method for each of such value.

Thanks very much
Andy

It is not clear what you want, can you explain your requirement

Note that any database transactions can not be done out of hibernate session

I know about Hibernate session and transaction. Let's say I have an entity (writing code ad hoc, may contain mistakes):



Now, let's say the entity is detached and the lazy attributes (person, note, price) are not initialized. I have a code, which can load @ManyToOne "person" already, just by calling em.find(Person.class, id); where "id" is from org.hibernate.proxy.LazyInitializer.getIdentifier(); So the code is generic for any LAZY @ManyToOne relationship, something like:



and that's it. However, I do not know, how to initialize "note" and "person" with some kind of such automatic or generic code. I did write a special HQL query for each of such LAZY value. And that's tedious.

Recently, I have made a method

dao.lazyGetValue(Order.class, order.getId(), "note")

which builds an HQL query like "SELECT e.note FROM Order e WHERE e.id=?". I have to search a little bit more, how to omit writing the "note" explicitly. That's not good for refactoring. It maybe be a solution to my question. It's just pity Hibernate has no method for such situations.

Andy

I guess my first question is why would you do that? You've already queried the DB for your object, why make that simple property lazy? Including that extra column in the original query is literally a no-cost operation, whereas requerying is REALLY expensive.

I get doing that for Object or collection associations where you're making your query more expensive by joining. And in the case where you KNOW you're dealing with a detached object, I've found most times it's actually EASIER just to query directly for that association.

Lazy loading's cool and everything, but making EVERYTHING lazy can actually COST you a lot of performance and headache and spaghetti code if you're not careful.

But I'm curious if there's some other constraint or reason you haven't explained here. I hesitate to tell you "do it differently" if that's not possible.

-Falken

I am using @Formula to count SUM() of rows or other not so trivial queries. I use @Formula, because it is very easy to filter or sort queries by Hibernate criteria, then.

Also, sometimes lazy loading is nice for very long Strings. E.g. consider "note" has 4000chars, which is 8000bytes. When you display a list of Order with paging of 100, then you have 800kb of the memory wasted for every request. It can make GC really busy. Furthermore, some modern RIA frameworks (Zkoss, Vaadin) store everything in the HTTP session. It can speedup the application. But then it's good to avoid loading unnecessary and large objects.

I do not LAZY requery everything. As I have stated, I use it just for tooltips ond other few less important things in my app. I want to find some "automatic" way how to load such LAZY values to avoid that spaghetti code.

Okay, that makes sense.

I guess my next question is why is the object detached? And why couldn't you just reattach it with a 'lock()' with a LockMode.NONE, and just let the property lazy load from there? Or if need be 'refresh()' though you'd requery that row, and maybe that's not desirable.

But you obviously have a session available if you can re-query. Seems like a slight session lifecycle change might work.

Or not?

-Falken

Well, lock() with a LockMode.NONE may be another solution. I have not examined it yet, since I do not know much about it pitfalls.

I have a DAO layer as J2EE session beans and above that a web layer (and a few more other services). Using lock() with a LockMode.NONE in this situation may lead to more "spaghetti" code. But the refresh may be usefull sometimes.

Thanks very much for the tip, Falken, I'll try that.