Hmm... I don't understand the limitation. I also see these:
*fails*: select _MAP['REGION_KEY'] from "sample-data/nation.parquet" order by cast( _MAP['NATION_KEY'] as INTEGER); *fails*: select _MAP['REGION_KEY'] from "sample-data/nation.parquet" order by _MAP['NATION_KEY']; *fails: *select _MAP['REGION_KEY'] from "sample-data/nation.parquet" order by 1; On Wed, Sep 4, 2013 at 11:53 AM, Jacques Nadeau <[email protected]> wrote: > Two problems in this query. > > First is you're sorting by a map field. We don't currently direct map > field expressions. You need to qualify to a particular scalar or repeated > field. > > The second problem is that the current code requires resolution of a field > rather than using * when you're trying to reference it elsewhere. > > therefore: > not supported: select * from "sample-data/region.parquet" order by 1 ; (map > keys are not currently referenceable and that is what this currently means) > not supported yet: select * from "sample-data/region.parquet" order by > _MAP['R_REGIONKEY']; (known issue we should fix in m2 or m3) > supported: select _MAP['R_REGIONKEY'] from "sample-data/region.parquet" > order by _MAP['R_REGIONKEY']; > > > > On Wed, Sep 4, 2013 at 11:39 AM, Timothy Chen <[email protected]> wrote: > > > Hi Jacques, > > > > It i rebased on the top of latest master. > > > > I am using a newer optiq release (0.4.11) so not sure if master has that > > problem. > > > > I will try later once I get a chance. > > > > Tim > > > > Sent from my iPhone > > > > On Sep 4, 2013, at 11:04 AM, Jacques Nadeau <[email protected]> wrote: > > > > > Is this on the tip of master? > > > > > > > > > On Wed, Sep 4, 2013 at 10:55 AM, Timothy Chen <[email protected]> > wrote: > > > > > >> Hi all, > > >> > > >> I'm getting a exception running a simple select * from > > >> "sample-data/region.parquet" order by 1 ; (or any field actually) > > >> > > >> error_type: 0 > > >> message: "Failure while running fragment. < > IndexOutOfBoundsException:[ > > >> dstIndex: 222 ]" > > >> ] > > >> at org.apache.drill.sql.client.full.ResultEnumerator.moveNext(R > > >> esultEnumerator.java:44) > > >> at net.hydromatic.optiq.runtime.ArrayEnumeratorCursor.next(Arra > > >> yEnumeratorCursor.java:44) > > >> > > >> A bit more digging it looks like it's from the RemovingBatchCreator > > trying > > >> to do a copy and getting a index out of bounds in the data > valuevector. > > >> > > >> Jacques suggested someone might be looking into this? Is someone > > lookling > > >> at fixing this arleady? > > >> > > >> Tim > > >> > > >
