[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=42157#action_42157 ] 

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

Well, after fighting a bit with this today I've come to the conclusion that while it's a bit better it's still not quite right for my case.

It looks like the AnnotationBinder processes the classes in hierarchical order but the construction of the Persister classes are still done in random order due to it just iterating over the classes Map values.

My real issue is that I have 20ish entities that have a similar filter that needs to get applied but i need to do some substitution on it to replace a column name and a table name.  I have a custom annotation that I'm parsing in the Persister that I was using to tack on the filter to the PersistentClass before it gets passed up the chain to build the filterHelper.

Something like this
{code}
    public MyPersister(PersistentClass persistentClass, EntityRegionAccessStrategy entityRegionAccessStrategy, SessionFactoryImplementor factory, Mapping cfg) throws HibernateException {
        super(handleFilters(persistentClass), entityRegionAccessStrategy, factory, cfg);
        Class<?> mappedClass = persistentClass.getMappedClass();
        VersionTable annotation = mappedClass.getAnnotation(VersionTable.class);
        versionTableName = annotation.tableName();
        keyName = annotation.keyName();
    }

    //have to handle adding the filters to the persistent class before the class persister is actually created
    private static PersistentClass handleFilters(PersistentClass persistentClass) {
        Class<?> mappedClass = persistentClass.getMappedClass();
        MyCustomAnnotation annotation = mappedClass.getAnnotation(MyCustomAnnotation.class);
        String tableName = annotation.tableName();
        String keyName = annotation.keyName();

        persistentClass.addFilter("myFilter", "my complex filter condition using the annotation values");
    }
{code}

So basically that allows us to define a rather nasty filter condition once and do some replacement when the persister is created.

Since there's no guarantee that the parent class is not processed prior to the sub class I had tweaked the Subclass.getFilterMap() method to return any filters that might have been added to the persistentClass directly as well as the ones on the parent class.

I've been carrying that around forever but have been trying to get to a vanilla release state ever since so I took another run at it this afternoon.

Barring any enforcement of order I'm able to get around having to mod the Subclass by leveraging the fact that MappedSuperClass now has filter support.  I end up adding a filter with a dummy condition that gets applied in the proper order during the binding, I skip adding the filter to the persistentClass in code and end up overriding the 

public String filterFragment(String alias, Map enabledFilters) throws MappingException {

method to do some token substitution of my own (in addition to Hibernate substituting the named parms)

In the end, it works w/o having to hack the core code so you guys can close this if you don't see any merit in processing the persisters in the same order that they were bound.  In the end I have to do the substitution each time a query is executed that has filters applied but it's cleaner maintenance wise 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