Question

I'm at a loss here, and perhaps it's something obvious because my Hibernate expertise is weaker than other areas.

In legacy code there is a Hibernate @Entity class Foo. One of the its properties is this:

private OldBar bar = new OldBar();

OldBar is an @Embeddable class that uses a single column, foobar:

@Embeddable
public class OldBar {

  private String fooBar;

  @Column(length = 10, nullable = false)
  private String getFooBar() {
    return fooBar;
  }

  @SuppressWarnings("unused")
  private void setFooBar(String fooBar) {
    this.fooBar = fooBar;
  }
}

The original problem is that I needed to do something with OldBar.fooBar, but the original design had limitations and had this field private, preventing me from subclassing it, so I had to create a whole other class, NewBar, to replace the other one and get access to the private field. I thought that since NewBar is also Embeddable and has the same @Column designation, I could just swap out the field in the class Foo:

private NewBar bar = new NewBar();

I wanted to do this because I have existing data in the foobar column, and I wanted to transparently use this data with NewBar instead of OldBar.

Through trace logs I've seen that Foo() is created, with its default version of NewBar(), as one would expect, when the constructor is called. However, by the time code calls Foo.getBar(), for some reason bar is null! I'm supposing Hibernate is setting it to null for some reason---but why isn't Hibernate reading the data from the foobar column and creating an instance of NewBar? Why does it star working again when I put OldBar back in in place of NewBar? Surely there's nothing in the database itself that says which of the @Embeddable classes is mapped to the column, is there?

Update: This gets stranger and stranger. Sometimes I'll let the code overnight, and the next day it works! Or the next day it doesn't work! Just now it didn't work (that is, the foobar property was set to null instead of the value in the database), so I made class ExactCopyOfOldBar and put it in the place of OldBar. It worked fine! So I switch back to NewBar---merely undoing my temporary changes. It still worked, when it hadn't before! Is there some sort of cache where Hibernate serializes values and doesn't get them from the database? This is very odd.

Update: Now I can no longer get NewBar to work at all. I create OtherBar, which is basically identical to NewBar except that it has a different name, and I plug it in and it works, correctly reading the embedded string. I switch back out to NewBar, and I get null again. What is going on?

Note that Foo is being loaded through net.databinder.auth.hib.AuthDataApplication.getUser(String username), which is simple enough:

return (DataUser) Databinder.getHibernateSession().createCriteria(getUserClass())
    .add(Restrictions.eq("username", username)).uniqueResult();

I've verified over and over again that the Foo (user) table has a single row with the correct data, and most importantly that the foobar field has data. Why is Hibernate returning me a Foo with a null foobar field? Why does simply switching from NewBar to OtherBar make it start working again? Why does it work all day and then stop working after I've left it overnight?

Was it helpful?

Solution

This may be the answer; I'll have to wait several days to see if it indeed fixes the problem. There are actually two parts.

First, for full disclosure, my NewBar class was actually a subclass of AbstractBar. I eventually wanted to have different type of embeddable bars, so I placed @Embeddable at the AbstractBar level, not at the NewBar level, and placed the private foobar field at the AbstractBar level as well. The funny thing is, this worked some of the time. And as I mentioned, sometimes I would come back the next day and Hibernate wouldn't load the foobar field. I don't understand why it didn't either work all the time or work none of the time.

Secondly, when I tried to get rid of this hierarchy so as to eliminate one source of the problem, I conflated AbstractBar and NewBar but forgot to bring the @Embeddable up from AbstractBar to NewBar, so Hibernate didn't see that was an embeddable class, and didn't know how to load a string into a NewBar field without an @Embeddable designation. This is why OtherBar (with an @Embeddable annotation) worked, but not NewBar (with no @Embeddable annotation). This much I understand. Why Hibernate didn't warn me that it couldn't figure out how to load a field, I don't know.

So to summarize, Hibernate won't load an embeddable field if you've left the @Embeddable annotation off the class. As for the original problem, I can only guess that @Embeddable is flaky when trying to use it on a class hierarchy, and that you're best off keeping all your embeddable fields at one level in the embeddable class. I hope that's the issue. We'll see if it continues to work tomorrow.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top