Hibernate version: v3.1 stable and today's SVN

Mapping documents:



Code between sessionFactory.openSession() and session.close():


Name and version of the database you are using:
RDBMS: Oracle, version: Oracle Database 10g Release 10.1.0.2.0 - Production
JDBC driver: Oracle JDBC driver, version: 10.1.0.2.0

Description of problem:

I'm a new Hibernate user so my apologies if I've missed something, but I've read everything I can find and I just can't come up with an answer.

I'm trying to use the XML mapping for Hibernate. In the above example, I have a table called ORGANISATION which has a foreign key onto ORGANISATION_TYPE.

I can instantiate and load Organisation (via dom4jSession.createQuery or by dom4jSession.load) and everything is there *except* the child element "organisationType" never loads properly. I say "properly" because the console shows the correct SQL to load the OrganisationType object, and in the debugger I can work down through the proxy to see that the real Element is there with the correct values.

In the above example, the debugger shows that the variable orgType is of class ElementWrapper and that orgType.element.li.target is my correctly populated Element with the expected attributes "id", "description", and "organisationTypeConstant", but the code:



returns null. Worse, if I change the mapping file for Organsiation's organisationType property to add the node attribute, EG:


then the tx.commit() raises the exception:


I've debugged it and this is because Hibernate sees that organisationType.id is null - which is technically correct given that the element has not properly loaded.

Again, sorry if this is something I should have picked up on but I'm really stuck and any help would be much appreciated - and if it is a bug, give me some pointers and I'll try and track it down but this is only my first week with Hibernate!

Regards,
John

Oops, there was a typo there: in the Java example, the orgType local variable is actually of type org.dom4j.tree.DefaultElement and it's member field "content" is of type org.hibernate.tuple.ElementWrapper...it's orgType.content.element.li.target that contains the correctly populated Element.

John

This problem is now a lot simplied (I did get a little confused when writing the report, my bad). Please read on:

I started lookin at the differences between node="organisationType" and node="organisationType/@id" on the many to one, because it's this that breaks the tx.commit() call. First though, I wrote a little dumpXml method - it's pretty boring, just a knocked together pretty printer for XML:



Without using "node" attribute on <many-to-one> at all, I get this:



So far so good, everything as expected. So I added the node attribute (as per docs)



and re run the code. I get:


It seems that node="org-type/@id" causes the element to be called "org-type" but creates a sub-element called "id" (instead of an attribute), and in that "id" element is the contents of the correct element (ie "id", "description", etc elements).

If I change the "node" attribute to just "org-type", then the node is built correctly using the org-type tag name instead of organisationType, it's only when you add the "/@id" (as per the docs) that it falls appart and interprets this as an attempt to create a sub element.

One final test - changing the node to "org-type/my-id" causes this:


Note that it still creates a sub-element, although this time you'd expect it to because you've specified so("node='org-type/my-id'") but the first character of "my-id" is missing.

Summary
When using node and embed-xml="true" do not use 'node="sometag/@id", it gives a strange and non-reversable structure.
When embed-xml="false" you can use either 'node="sometag"' or 'node="sometag/@id"' - the first form puts the id in as a child text node, the second as an attribute of the child - but in either case they pass back though tx.commit() successfully.

I'm about to start debugging the part where the value of the node attribute is interpretted - any leg-ups on where to look would be real helpful.

Regards,
John

Having looked at the code, the "bug" is debatable - either it's a problem with what the mapping file permits as a valid value for the "node" attribute, or it is a problem where the generated child Element should have an attribute created to match the node expression (it doesn't, which is what causes the exception during tx.commit()).

(Note that this is only when embed-xml="true" ... embed-xml="false" works as expected)

I would guess that the argument would be that if the child is embedded then the parent has no right in determining how it's contents are defined - doing so implies an inconsistent data format at least, never mind discussions about design purity. The only thing the parent can do is choose the child's tag name, and as it seems redundant to allow the parent to nest elements, neither a "/" or a "@" should never be present in a node attribute when embed-xml="true". This also happens to be the simplest fix! :)

I'll do the fix if someone will give me the go-ahead? I think it's in Dom4jAccessor.getSetter...

IMHO this leads onto another discussion of whether embed-xml is actually needed at all - if DOM4J and POJOs are a mechanism for exposing the OR data, then embed-xml is really about how that data is serialised into a non-relational format. The biggest failing of embed-xml is that different business functions will require the same object to be embedded (or not), depending on circumstances. IE it's a runtime decision, and not a pre-compiled decision.

What does everyone think?

John