-
Erik Froseth authored
A lot of our MTR tests are non-deterministic in the sense that the don't have any ORDER BY. Traditionally, this hasn't been a problem since our storage engines and execution engine has a somewhat reliable output order. This will however break when we introduce i.e. new join methods. To fix this, we add --sorted_result to these non-deterministic tests. We add --sorted_result instead of modifying the query whenever possible, to avoid changing the execution plan. Also, a query in MTRs check_testcase() is modified to have an ORDER BY, so it becomes deterministic. The GIS test suite contains quite a few polygons where the direction of the rings are wrong. Some of the GIS functions will automatically correct the ring direction, but different execution plans may actually change when and if this happens. We have therefore corrected some of these test so that we always pass in a polygon with correct ring direction. Change-Id: Iaa10cd8fc8f8ba50f6403d3dc5ea266cd3527c54
Erik Froseth authoredA lot of our MTR tests are non-deterministic in the sense that the don't have any ORDER BY. Traditionally, this hasn't been a problem since our storage engines and execution engine has a somewhat reliable output order. This will however break when we introduce i.e. new join methods. To fix this, we add --sorted_result to these non-deterministic tests. We add --sorted_result instead of modifying the query whenever possible, to avoid changing the execution plan. Also, a query in MTRs check_testcase() is modified to have an ORDER BY, so it becomes deterministic. The GIS test suite contains quite a few polygons where the direction of the rings are wrong. Some of the GIS functions will automatically correct the ring direction, but different execution plans may actually change when and if this happens. We have therefore corrected some of these test so that we always pass in a polygon with correct ring direction. Change-Id: Iaa10cd8fc8f8ba50f6403d3dc5ea266cd3527c54
Loading