[hibernate-issues] [Hibernate-JIRA] Created: (HHH-3816) Map joins as XML in a column

[Paul Murray (JIRA)]

Map joins as XML in a column
----------------------------

                 Key: HHH-3816
                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3816
             Project: Hibernate Core
          Issue Type: New Feature
          Components: core
    Affects Versions: 3.3.1
            Reporter: Paul Murray


We are working with a hibernate-centric relational model written by a third party (ie: the database schema is generated from hibernate). It uses a lot of subclasses and one-to-many buckets, where the items in the buckets are essentailly beans. Hibernate persists this as a database schema with hundreds of tables. Great for hibernate, but lousy to write SQL against.

XML does a great job of handling data items that are buckets of other data items, and data itens that are just beans. However, it's lousy at doing relational data - many-to-many associations.

What I would like in hibernate is an ability to say that a one-to-many collection of beans is to be stored as serialised XML in a column (a varchar or CLOB). That is, a new strategy in addition to the ones mentioned here http://www.hibernate.org/346.html . I'd like to be able to specify the xml document type, schema, namespace and so on to be stored in that xml, so that the resulting column contains a complete, valid document. It would even be nice if hibernate could generate the xml schema, so that I can validate input. 

If items in that collection contain relational links that are not embedded xml, then it might be nice if the link (which hibernate needs to be able to understand when it is pulling the data into memory as beans) somehow conforms to XPath. Of course, the easy way to manage this is that hibernate can simply refuse to do it.

Perhaps, in addition to collections, one might be able to sepcify that a group of fields (including collections etc) are all stored in a single database column containing XML. Thus, an ADDRESS table might have an address_id and status stored as database fields, but the address contents - street number etc etc - could all be jammed into a single XML chunk in a CLOB column named "address stuff".

This means that my actual logical relational entities get stored as relational tables, which is what an RDBMS is good at; but the reams and reams of sub and sub-sub-sub detail records get put in XML, which is what XML is good at. 

* I get a small(er) number of tables
* my database is not cluttered with a load of specific little tables holding unintersting collections
* the structure of the data stored in detail-type items can be extended without database schema changes
* the identifiable nuggets of user-editable data can be associated with stylesheets to convert them to html, and xforms for editing them
* there's a clear separation of stuff that embodies the logical structure of the data from stuff that's content data



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira