I meant have a non-nullable field in Demographics. Such as: class Demographics {
private int dummy; public int getDummy(){ return dummy; } public void setDummy( int value) { this.dummy = dummy; } } Because this is a primitive, the "uninitialized" value is "0" and not NULL, so Hibernate will persist a "0" and force creation of the Demographics object on retrieval to store that "0". The problem with what you have is that your constructor sets the value of demographics to something non-null, and Hibernate comes along and populates the "correct" null value retrieved from the database. After all, you don't really have demographics if all of the properties are null. There are other legitimate cases where you really can have an embeddable object with all null properties, but I digress. As I think about it… why not change the getter? public Demographics getDemographics(){ if (demographics == null) demographics = new Demographics(); return demographics; } It's not what I think of as a getter, but I've done worse things. I'm not sure if there's a down side to it, but it feels less hack-ish that polluting your database with useless information. Well, there you have it, try modifying your getter. It feels less bad. On Mon, Feb 2, 2015 at 2:46 PM, nhhockeyplayer nashua <nhhockeypla...@hotmail.com> wrote: > Thanks Jonathan. > > Person.JAVA > private Demographics demographics = new Demographics(); > > is this what you meant? I though this is already sufficient for hibernate > because its original code and this worked before so I am wondering why it > isnt working now...thats why I felt it was schema issue. > > > Best regards > and thanks... KEN > > From: nhhockeypla...@hotmail.com > To: users@tapestry.apache.org > Subject: RE: @Embedded properties null not supported in T5.4 ??? > Date: Sun, 1 Feb 2015 07:34:00 -0500 > > > > > this could be a database schema issue > > i restored a partial group of entities on this shema from past rev > > likely it is that and I should start clean > > I wonder what the schema migration semantics are for large scale systems > > years ago at Hewlett Packard we operated a fairly commercial one that ran at > setup time and overlayed > -- Jonathan Barker ITStrategic --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org