[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2544) Create the EntityPersisters in order based on Inheritance hierarchy

[Shawn Clowater (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42148#action_42148 ] 

Shawn Clowater commented on HHH-2544:
-------------------------------------

It looks like ordering might have been applied somewhere along the way, I was following HHH-2394 that was bumped recently and was looking at what I was doing for my filters and subclasses and it looks like the hack that I have in place may no longer be required.

I'll remove my local patch and rebuild and will let you guys know if you actually fixed this along the way for me.

> Create the EntityPersisters in order based on Inheritance hierarchy
> -------------------------------------------------------------------
>
>                 Key: HHH-2544
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2544
>             Project: Hibernate Core
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 3.2.3
>            Reporter: Shawn Clowater
>            Priority: Minor
>
> I have a bit of what might seem to be an odd request.
> I had run into a scenario where filters on my mappings that were part of a Single Table hierarchy were not getting into the configuration and it turned out it was based on the order that the EntityPersisters were being created as we've doing some minor magic with Custom EntityPersisters for filters.
> In our case we have a filter template where the filter is pretty much the same for each class that implements it except for the table and key name used in the filter.
> So, rather than define this annotation everywhere (we had previously been using xdoclet to generate it for the hbm mappings) we pushed the logic into a Custom Persister.
> So, essentially as it is building the EntityPersister we intercept the PersistentClass before it calls the super() constructor and add our required filters on the PersistantClass (in its FilterMap) before it gets passed up.  This is done like this because by the time it gets to the  AbstractEntityPersister's constructor it uses the filterMap to construct the FilterHelper and then you're done as you have no access to change that after it is built.
> So, in the Inheritance case any subclasses that are built before the main root class will not have the filters that we inject during the construction of our Custom Entity Persisters.  I have temporarily worked around it by changing the Subclasses getFilterMap() method to not only return the filters from the Parent class but also from the class itself.  Now, normally you can't define the filter on the subclass but I can through the persister.
> What I'd like to do is:
> Make the persister class for the subclasses a 'standard' persister that doesn't add any filters to the subclass.
> Still have my root class' entity persister adding the filters.
> But have the Entity Persisters built in hierarchal order in the SessionFactoryImpl.
> Since they are being built in any given order right now, I can't see an issue with providing some order to them, something like the AnnotationBinder does.

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