Invalid parameter index SQLException when using named parameters after positional parameters
Description
This one is a little odd, but I had a query that used to work and no longer does. The attached test case displays the problem. For whatever reason we had a query that had 4 positional parameters followed by a named parameter. The query used to work, up to 3.1 beta3 (from cvs) at least, after upgrading to 3.1(and 3.1.1) it fails. Hibernate attempts to set the named parameter with an invalid index, like 9 instead of 4.
Now, one could argue that it is goofy to mix named and positional parameters. I don't totally disagree, but I'd like to make two points. First, it used to work. Second, if you set the named parameter value first, and then the positional ones, an exception is thrown indicating that postional parameters can't be set after named ones. However, no such exception is thrown setting the positional ones first, indicating that either there's a missing exception, or it is supposed to be allowed.
If you don't want to revert the functionality back to the way it was, I would suggest throwing an exception when mixing named and positional paramters. However, my main concern is that in order for this bug to surface, something somewhat significant must have changed with the query mechanism, and I wonder what else may have been affected.
Note: the attached test case only has the last directory entry in the path under "test\org\hibernate\test".
Well, maybe I shouldn't say significant, but it seemed like a weird error to come out of a minor patch change. Just concerned as a paranoid developer is all. Thanks.
Steve Ebersole January 24, 2006 at 9:51 PM
Don't understand what makes you think that "something somewhat significant must have changed", but ok...
This one is a little odd, but I had a query that used to work and no longer does. The attached test case displays the problem. For whatever reason we had a query that had 4 positional parameters followed by a named parameter. The query used to work, up to 3.1 beta3 (from cvs) at least, after upgrading to 3.1(and 3.1.1) it fails. Hibernate attempts to set the named parameter with an invalid index, like 9 instead of 4.
Now, one could argue that it is goofy to mix named and positional parameters. I don't totally disagree, but I'd like to make two points. First, it used to work. Second, if you set the named parameter value first, and then the positional ones, an exception is thrown indicating that postional parameters can't be set after named ones. However, no such exception is thrown setting the positional ones first, indicating that either there's a missing exception, or it is supposed to be allowed.
If you don't want to revert the functionality back to the way it was, I would suggest throwing an exception when mixing named and positional paramters. However, my main concern is that in order for this bug to surface, something somewhat significant must have changed with the query mechanism, and I wonder what else may have been affected.
Note: the attached test case only has the last directory entry in the path under "test\org\hibernate\test".