My understanding of Jacques' proposal is that he suggests we use .drill instead of requiring the user to do an explicit cast in their select query. That way, the changes for enhancement would be restricted to the scanner.
Did I interpret the alternative approach correctly? -- Zelaine On Mon, Oct 26, 2015 at 4:05 PM, Hsuan Yi Chu <[email protected]> wrote: > Hi, > > Luckily, we will have hang-out tomorrow. > > Maybe we could have an example to elaborate how .drill can be used in a > cast-query? > > Thanks. > > > On Mon, Oct 26, 2015 at 3:31 PM, Neeraja Rentachintala < > [email protected]> wrote: > > > Jacques > > I have responded to one of your comments on the doc. > > can you pls review and comment. I am not clear on the approach you are > > suggesting using .drill and what would that mean to user experience. It > > would be great if you can add an example. > > > > Similar to other thread (initiated by Julien) we have around being able > to > > provide file parsing hints from the query itself for self service data > > exploration purposes, we need this feature to be fairly light weight > from a > > user experience point of view. i.e me as a business user got hold of some > > external data, want to take a look by running adhoc queries on Drill , I > > should be able to do it without having to go through whole setup of > .drill > > etc which will come later as the data is 'operationalized' > > > > thanks > > -Neeraja > > > > On Mon, Oct 26, 2015 at 2:49 PM, Jacques Nadeau <[email protected]> > > wrote: > > > > > Hsuan was kind enough to put together a provocative discussion on the > > > mailing list about skipping records. I've started a way too long thread > > in > > > the comments discussion but would like to get other feedback from the > > > community. The main point of contention I have is that the big goal of > > this > > > design is to provide "data import" like capabilities for Drill. In that > > > context, I suggested a scan based approach to schema enforcement (and > bad > > > record capture/storage). I think it is a simpler approach and solves > the > > > vast majority of user needs. Hsuan's initial proposal was a much > broader > > > reaching proposal that supports an arbitrary number of expression types > > > within project and filter (assuming they are proximate to the scan). > > > > > > Would love to get others feedback and thoughts on the doc to what the > MVP > > > for this feature really is. > > > > > > > > > > > > https://docs.google.com/document/d/1jCeYW924_SFwf-nOqtXrO68eixmAitM-tLngezzXw3Y/edit > > > > > > > > > -- > > > Jacques Nadeau > > > CTO and Co-Founder, Dremio > > > > > >
