I have taken the xml data binder and made an unbinder. Though I changed the terms to be XmlWriter and XmlReader. The XmlWriter is the data binder with the additional ability to select which properties and objects get put in the xml. The xml reader will read in the output of XmlWriter and generate the appropriate object graph. It uses similar idioms to ObjectInputStream (i.e. a global readResolve() method)...

Is this something that the hibernate team would be interested in as a submission? If so what should do you require/want with it?

It works for my case but would need work for other cases.

[list=]works only if unique id's are unique to the database (easy to fix)
[list=]does not work with composite keys (a little more work to fix)
[list=]not all data types are supported since they don't all properly implement the fromString() and toString()... For example DATETIME.fromString( DATETIME.toString() ) would result in a date format error. Currently I get around this with a few hacks but ideally changing the fromString()/toString() methods in hibernate.type is the way to fix this.

Anyway it isn't my intention to make it seem like the code is not ready for prime time. It is and is being used successfully in a production environment. It is just that Hibernate is a very complete product with many features that I do not have in my current environment.

Also there are a few bits that would make the code much simpler if Hibernate were to expose it's api a little differently in places. Nothing earth shattering but would allow the XmlReader to not be as fragile between Hibernate code changes.

My main use for this is we have distributed databases. Each client has there PC with a database. We need to do all sorts of synchronizations. We previously were maintaining a set of castor mappings for xml and hibernate mappings for the db transactions. With this code we use the hibernate mappins for everything. In the case of synchronizations we move a persisted object from Machine A to Machine B. When it gets to Machine B we strip the ket information from the persisted objects so we can persist them in Machine B.... This is done via a global readResolve() that is caled on all restored objects in the XmlReader....

The reason the XmlWriter can selectively omit properties from the XML is the way our databases are structured you could easily pull a single item and end up pulling the entire database with it. Being able to define boundaries on what data to pull was essential (the difference between a 40K transaction and a 40 meg transaction LOL)

Anyway I look forward to hearing comments...
[/list]