I've mapped a "one-to-zero-or-one" relationship as explained below:

Association: Person [1 <--> 0..1] Note

Mapping documents:


Query:


The generated SQL (show_sql=true):

PostgreSQL SQL Result:


Hibernate version: 3.1 rc2
Name and version of the database: PortgreSQL 8.0.3

When I excute the query all persons that do not have a matching note should be null, but a note proxy is returned by Hibernate. The generated sql does the left join but the 'initialized' property in proxy (org.hibernate.proxy.CGLIBLazyInitializer) is set to 'false'. That shouldn't be happening, isn't it? Note should be null.

Can someone from Hibernate team help me with this issue? I think it is a bug in Hibernate since the result is inconsistent. It should be null but a proxy is returned.

Not a bug at all. HIbernate 3 defaults to using proxies while H2 did not (see conversion notes). Thus you require a change to your mapping. eg,

David,
I know Hibernate 3 defaults to using proxies and that is a choice done by Hibernate 3 that I really like, but Hibernate 3 also allow us to override the lazy declaration of the mapping file using "left join fetch":
select person from Person person
left join fetch person.note
where person.id = :id

From Hibernate Reference Documentation:



And the outer join really happens as the generated query shows:
select person0_.id as id5_0_,
note1_.id as id6_1_,
person0_.name as name5_0_,
note1_.note as note6_1_
from person person0_
left outer join note note1_ on person0_.id=note1_.id
where person0_.id=?

But why a proxy is still returned in note association? Shouldn't it be null as the result of the above query? Note that id6_1_ and note6_1_ are null.

use a <one-to-one since you're joining with the PK instead of a regulal FK

Emmanuel, thanks for your reply.

The problem is that sometimes we really need a lazy "one-to-zero-or-one" relationship. If we would change to a lazy one-to-one we would have to use the constrained attribute in 'one-to-one' element which forces a not null attribute. But sometimes a person doesn't have a note.

The use of "many-to-one" mapping that we did fits perfectly to our needs. It gets a proxy when we don't use eager fetching. It gets the right note when we use eager fetching, but it gets a proxy when there is no note associated to the person. So it works almost perfectly, except that when we force eager fetching in null notes, Hibernate hydrates person objects with a proxy and not with a null reference.

I know that I could add a FK in note table and solve my problem, but why should I do that if I can use the same person PK? If Hibernate would return null when there is no note it would be just right. I just would like that the following mapping should work as stated above. I think that when we get a proxy when an eager fetching is used is an inconsistent result. In our case, we are using a workaround to detect and fix this situation, but we wanted to report it as a way to help other people who may face the same problem and maybe to help Hibernate become even better.

Many-to-one mapping:


Our problem is not so rare. We found other people in this forum facing the same lazy "one-to-zero-or-one" problem, but the solutions were "non-lazy one-to-one mapping", "lazy not-null one-to-one mapping using constrained="true"" or "many-to-one mapping using a foreign key (FK)". We are suggesting one more solution to the problem: "many-to-one mapping using the same primary key (PK)". I hope that can help someone else.

Hibernate cannot replace a proxy with a null, this is not possible in Java wo bytecode enhancement.
So wo does hibernate know whether it needs to create a proxy or set null? The only solution is to load the second row. Check the wiki comunity area, there is a page dedicated to the non one-to-one lazyness

I read somewhere in a post that you can use byte code enhancement to achieve proper lazy loading with null semantics in version 3.x. ie., no-proxy.

If you don't have a problem with byte code enhancement then this *would* be a good solution but I also read that the byte code enhancement solution is broken in 3.0.x but is fixed in 3.1.x so you'd have to be using the latest 3.1.x release candiate version to make it happen for you.

I personally am not a big fan of the proxy solution. A team I was involved with built a home grown O/R mapper back in 2001 and it had similar issues. It can also play havoc with your freedom of OO expression in modeling (which should be treasured as much as your freedom of speech!).

Emmanuel and Chrisco, thanks for your help.

But as Chrisco said, we are not fan of bytecode enhancement too. So reading and reading and (...) Hibernate Reference we decided to try the many-to-one attribute 'not-found="ignore"' and it worked!!!
So a person with no matching note has its note association set to null by Hibernate!!!
The final Person mapping is listed below:


The only difference is not-found="ignore" in note association.
So we have one more working alternative to a lazy "one-to-zero-or-one" association in Hibernate.

The use of not-found="ignore" results in a non-lazy property. So lazy "one-to-zero-or-one" in Hibernate is not possible yet. We can use non-lazy "one-to-zero-or-one" or a lazy one-to-one association.
And I undestand now that .

And thank you all for help...

Looks like byte code enhancement (but only if you can use >= 3.1.x) is the only option.

I don't have a problem with byte code enhancement if it makes the semantics of NULL work properly (I love using that word semantics - a lot of people who know what they're talking about use so I thought I'd give it a try!)

Like I said before if you have very realistic object models and therefore need polymorphism to function properly through a lazily fetched relationship (which proxies can't do) then byte code enhancement is your only option. I just can't wait till 3.1 release candidate gets accepted then I will use it with byte code enhancement on.

I need things to work correctly and to place no contraints on the ability of my code to express complex object models and access inheritance hierarchies polymorphically. I don't care if I have to byte enhance my code even though byte code enhancement is a blasphemus term to some in these parts.

I think the anti byte code enhancement sentiment goes back to the days of the war between Hibernate and JDO. The use of byte code enhancement seemed to be a very explosive topic in that war but that war is virtually over and Hibernate is winning so get over it everyone - it's ok to use byte code enhancement now. To the victor go the spoils - if it means your project can employ polymorphic elements without restriction and the notion of NULLs can be employed then I say "get over it and go for it!"

This was not a JDO/Hibernate war argument. This is a real concern we still have in the team. We do not like enhancement for very good reasons(tm).
1. Bytecode enhancement is used to lazy attributes which is usally not a good optimization.
2. Bytecode enhancement complexify/slows down you code - test cycle
3. Bytecode enhancement is less lazy than proxy in most cases. The object has to be loaded the minute you get a pointer on it.
4. Bytecode enhancement just fail to lazy public fields unless you enhance all your application/client code.

To comment on each of your issues:

1. I agree - why would you bother lazy initializing individual attributes (unless they were hugs BLOBs or something). Most of the time I would only bother lazy fetching association relationships.

2. If my compiler can compile 100s of java files in less than a few seconds then I'm sure byte code enhancement wouldn't add that much extra time to a compile-test cycle. Besides - my keyboard needs a break to cool down ;). It would be interesting to hear from some of the people with byte code enhancement experience to find out how much extra time byte code enhancement adds.

I would judge that it is a much more serious and costly addition to the design - code - test cylce if developers can't use polymorphism through lazy fetched relationships (because lazy loading is implemented via proxies) or have issues with NULL. Not being able to correctly implement a sophisticated OO model with complex polymorphic relationships and not being able to test for NULL properly would cost my team a lot more than an extra second or so of byte code enhancement time. The later I can fix by buying faster PCs or adding more RAM the former can't be fixed and the results are a lower quality, less OO design.

3. Isn't that the definition of lazy loading anyway - it only gets fetched when you access it. Why would you access it if you didn't need it?

4. Now who would be creating public fields in this day and age anyway? :)
If you know someone who's doing that then they've probably failed "Introduction to OO Programming 1.0.1" and should immediately be sent to their "naughty spot" for 30 minutes.

Hi guys,

Just a small comment - there is *no* problem in using polymorpishm with respect to associations in hibernate. The issue you have is about representing NULL, something that is more related to the kind of datamodelling people tend to do and not OO. The users I see having problem with polymorphic associations are mostly those who want to downcast their objects which again is something that is arguable OO.

And note, that just because there *can* be a association defined between two objects, doesnt mean it *has* to be physically represented in your object model.

In any case, all is possible now with H3.1, so go buy your bigger machines ;)

/max

Thanks for your quick response Max.



When I have modeled -to-zero-or-one or -to-zero-or-n relationships I just want to be able to continue to code like:



Where insurance policy classes are subclasses of an InsurancePolicy class - there could be a whole heap of them all implementing makeClaim in slightly different ways.



Yes, well there's real OO (where every character in a string is implemented as an individually instantiated character object - eg., Smalltalk language) and there's practicle, usable OO. And sometimes in practicle, usable OO you need to downcast.

Like when you have implemented methods that, for type safety reasons (detected at compile time, not run time), take a specific subclass as a parameter.



You can't just pass a reference to the super class (eg., insurancePolicy) to these methods. The compiler won't let you pass the proxy in for this parameter and you won't be able to cast it either.



I agree with that. If you have a one-to-one why not just merge the two objects into one... but if you have a one-to-zero-or-one then you can't merge them.



Kewl! So byte code enhancement is all good and stable in 3.1?