Query plan for query using filter with variable number of parameters is incorrectly re-used

Description

It looks like the QueryPlanCache is incorrectly reusing an existing query plan when it shouldn't. This happens in the following situation

  • A filter is used by the query

  • The filter has one parameter where the values are a Collection/Array

  • The number of parameter values changes from query to query

Debugging the hibernate code it looks like HQLQueryPlanKey is not correctly considering the NUMBER of parameter values for enabled filters.

To reproduce do the following.

  • Define an entity with a single filter def and filter with one parameter

e.g.

@FilterDef( name="partitions", parameters = @ParamDef( name="partitionIds", type="integer" ) )
@Filters( {
@Filter( name="partitions", condition="partitionId in ( artitionIds )" )
} )
public class Account

  • Create a new session

  • Enable the "partitions" filter

  • Define a list of length 2 and set the "partitionIds" parameter on the filter

  • Execute the query

  • Works fine

  • Close session

  • Create a new session

  • Enable the "partitions" filter

  • Define a list of length 1 and set the "partitionIds" parameter on the filter

  • Execute the query

  • Exception executing query because the plan generated from the first query is being used again which expects two parameters (?, ?) in the list when only one is being supplied in this instance.

Suggested fix.

Modify QueryPlanCache.HQLQueryPlanKey to account for the number of parameters in the enabled filters in addition to the filter names. The information is passed in to the constructor of HQLQueryPlanKey should this shouldn't be difficult to fix.

Also noticed that FilterQueryPlanKey may suffer from the same issue.

In the meantime is there any workaround for this issue?

Environment

None

Activity

Show:
MikeQ
August 10, 2010, 10:53 PM

On further investigation this appears to be fixed in 3.5.4. Will test and close if this is the case.

Assignee

Unassigned

Reporter

MikeQ

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure