Andrew McIntyre (JIRA) wrote:
and since all the tests pass with or without ruleBasedOptimization set to true, I'll leave that off. Not really worth investigating, since it seems to have no effect on the new test.
Unless of course setting that property to true revealed an error once upon a time and that error was fixed, thus removing the error. In that case setting or not setting the property would lead to the same behavior, which is in itself confirmation that whatever the old error was (if there was one) is actually fixed.
Or as a different (and more pertinent) example: setting the optimizeJoinOrder property to "true" (which is also the default) exposes a bug that results in an error--namely, DERBY-2500. If I fix that bug (which I hope to!) then running the query should return the same results regardless of what optimizeJoinOrder is set to--i.e. optimizeJoinOrder will at that point "have no effect on the test". But in the interest of regression testing we still want to make sure the query is run with optimizeJoinOrder=true (the default) as proof that DERBY-2500 is fixed.
Maybe something similar once existed for "ruleBasedOptimization=true"...? *shrug* Army
