[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3439) Change o.h.cfg.Mappings to not require constructor

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_30940 ] 

Steve Ebersole commented on HHH-3439:
-------------------------------------

I've been thinking about it as well ;)

Its not Emmanuel.  Mappings are constructed via the Configuration#createMappings.  You (annotations) extend Configuration therefore in your theory you do have control over how Mappings are constructed.  The issue is that that is not *really* the case because Mappings is a class with a very specific constructor; and since you also extend Mappings (you have to since the class itself is the contract rather than an interface) you must comply with that constructor signature.  

As I mentioned to you on IRC, I see 2 solutions as being viable:
1) Make Mappings an interface, and have an impl of that interface as a non-static inner class of Configuration giving it access to those collections directly on Configuration (the Collection on Mappings *are* the ones dirdctly from Configuration now anyway).  Configuration extenders can then simply define a new Mappings class extending Configuration#MappingsImpl.  Had we done that prior to adding fetch profiles, for example, there would have been no signature changes affecting your code here since all pertinent changes would have been  handled for you in Configuration#MappingsImpl which is where that stuff is actually a concern (almost like real OO programming!) ;)
2) Make Mappings a delegate for Configuration.  The essential change here is to have Mappings itself instantiate and manage these collections instead of Configuration doing it and passing them in as ctor args.  Now this does change the current semantics of Mappings slightly in that we currently build a new Mappings instance for each <hibernate-mapping/> we encounter.  And in fact the javadocs for Mappings even assert this usage.  *However* that semantic is completely anecdotal.  All these collections on Mappings are not segmented by the Mappings instance because they are the collection instances maintained on Configuration!  The only Mappings attributed that are truly used in that fashion are the non-collection member attributes (schemaName, catalogName, etc) which come directly from the <hibernate-mapping/> element.  And that is easily "corrected" for this approach by resetting those to null/etc when we start processing a new <hibernate-mapping/> element.

> Change o.h.cfg.Mappings to not require constructor
> --------------------------------------------------
>
>                 Key: HHH-3439
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3439
>             Project: Hibernate3
>          Issue Type: Improvement
>          Components: metamodel
>            Reporter: Steve Ebersole
>            Assignee: Steve Ebersole
>             Fix For: 3.4
>
>
> Mappings requiring passing all the mapping queues into its constructor causes interoperability issues with other components (annotations e.g.) because they generally extend Mappings to add extra information.  Therefore we introduce an incompatibility whenever we add a new mapping attribute because we are currently forced to change the signature of the Mappings constructor.
> A better approach is to make Mappings an interface with an impl that defined as an inner class to o.h.cfg.Configuration so that it can expose access to the queues directly from there.  Annotations, etc can than simply extend that Mappings impl. 

-- 
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