[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-530?page=co... ] Shawn Clowater commented on HHH-530: ------------------------------------ Steve, the above patch fixes an issue I had with my orginal. I'm not extremely happy with the instanceof check but it was the only way that I could handle the 2 cases w/o making some broader API changes). It addresses the fact that as you get deeper and deeper into a subquery stack you don't have the session readily available to get the enabled filters off of. I've also expanded the DynamicFilterTest suite to include a few more Criteria examples and added the HQL ones as I've been banging my head against the wall seeing if there was a silver bullet short term solution to having it all play nicely. On the Criteria side of things I believe it all hangs together it is the HQL side that was the rat's nest for me. Mere mortals shouldn't be bombing around inside the AST parser. I will say that the move the maven and the pom files are a godsend. It is some nice to be able to have the project quickly up in Idea in order to do things like debug single unit tests, etc. I think you're right in it would be nice to have the parameters in the HQL AST tree. Some of my observations with the problems in HQL that you probably already sorted out for yourself are: -if there are 0 named parameters then simply commenting out the overloaded bindParameterValues in QueryLoader allows the filters to be applied to the HQL (with the addition of commenting out the piece in JoinProcessor -again the issue with the named parameters is that by the time the parsing is done they have essentially been replaced by positional parameters. I tried to get those values back into a preprocessedPositionalParameters array or something that the processFilters piece could use but during the parsing phase there didn't seem to be any access to the QueryParameters in order to do that. (which makes sense now once I realized that the parse in done when generating the HQL plan). ****Will this mesh with your idea of having the values in the HQL AST tree and pulling their values since the plan can be cached. I would think you'd need to throw out the plan if any filters are enabled as the resulting HQL could be different in each case? -assuming that you can get the filters into the tree before the parsing, I think it is a simple case or just finding the ":" like it is now and then checking to see if the named param after that matches a filter, if it does then build a DynamicFilterParameterSpecification, otherwise it is a simple NamedParameterSpecification. -If the DynamicFilterParameterSpecification can be properly built then you wouldn't need to call the processFilters piece as everything would have been parsed in the correct order so you would want to skip parsing the complete query a second time from the loader. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira