[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-530?page=co... ] Shawn Clowater commented on HHH-530: ------------------------------------ First of all. Thanks for taking a look at this. Even if it is only for 3.3, I'll manually patch 3.2.6 (when it arrives) if I have to. Hopefully, it's as simple a change as I've boiled it down to for the short term but I've tested it on a query that had at least 3 subqueries with filters at multiple levels for a grand total of 94 parameters (eek) and it sorted itself out. The original patch was fancier but I think it failed in certain cases and of course was no longer relevant. As for the mixed positional/named it seems to be restricted right at the parser level before it even gets to the parameter processing so that was good enough for me as my change doesn't seem to affect or change that behavior as far as I can tell. But, it looks like you're saying that there are cases where this doesn't hold true? Also, I stumbled across some class (I forget the name) that it looked like you had future use for it with the filtering aspect of things but again, for the short term, it would be nice if the functionality at least worked even if it wasn't what will be in the grand vision. Bear in mind that the SubqueryExpression also needs to be modded in order for the filters to be passed to the CriteriaJoinWalker. This is what I'm using at the moment as the current state of the world passes in new HashMap() for the enabled filters. CriteriaJoinWalker walker = new CriteriaJoinWalker( persister, innerQuery, factory, criteriaImpl, criteriaImpl.getEntityOrClassName(), ((CriteriaImpl) criteria).getSession().getEnabledFilters(), innerQuery.getRootSQLALias()); -- 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