IC. Actually when I set limit=4, it returns in the expected order. That was why the test previously did not fail.


On 5/15/13 10:57 PM, "James Taylor" <notifications@github.com> wrote:

In src/test/java/com/salesforce/phoenix/end2end/salted/SaltedTableTest.java:
> @@ -438,4 +438,24 @@ public void testSelectWithGroupBy() throws Exception {
>              conn.close();
>          }
>      }
> +
> +    @Test
> +    public void testLimitScan() throws Exception {
> +        long ts = nextTimestamp();
> +        String url = PHOENIX_JDBC_URL + ";" + PhoenixRuntime.CURRENT_SCN_ATTRIB + "=" + (ts + 5);
> +        Properties props = new Properties(TEST_PROPERTIES);
> +        Connection conn = DriverManager.getConnection(url, props);
> +        try {
> +            initTableValues(null, ts);
> +
> +            String query = "SELECT a_integer FROM " + TABLE_WITH_SALTING + " WHERE a_string='abc' LIMIT 1";
This isn't what I was thinking about. The issue I'm thinking about is where the LIMIT would span across a region boundary causing the results you get back to not be sorted according to the PK. Can you modify your test to test this?

I'm fine documenting this issue - essentially that the starting point of a limit scan may be different on a salted versus unsalted table.

-
Reply to this email directly or view it on GitHub <https://github.com/forcedotcom/phoenix/pull/208/files#r4249555> .