I would think if we want to expose the timestamp field, we should add another layer of nesting. In other words, every qualifier, which is currently a single value, would actually be a map, which includes a value field and timestamp field. Of course, we could also take it a step further and expose versions as well, in which case each qualifier would be a repeated map.
There's also the idea of using table functions to modify the table scan using the API of the underlying storage if there is something that is not easily expressed via SQL. On Wed, Oct 21, 2015 at 12:05 PM, Jacques Nadeau <jacq...@dremio.com> wrote: > We've talked about how to expose this but haven't yet exposed it. What do > you think a good way to expose this would be? A separate set of columns > (e.g. qualifier and qualifier_timestamp)? Do you also need access to > multiple versions or only the timestamp? > > -- > Jacques Nadeau > CTO and Co-Founder, Dremio > > On Tue, Oct 20, 2015 at 6:33 PM, Grant Priestley < > grant.priest...@colesfinancialservices.com.au> wrote: > > > Hi Drill Developers, > > > > > > > > I am hoping to introduce Drill into a Big Data environment in the hopes > of > > supporting analysts with temporal queries off HBase. After going through > > the documentation online, I havben’t been able to find if Drill is able > to > > leverage HBase’s get.setTimeRange() when querying data within HBase. > Does > > this functionality exist in Drill 1.2.0? > > > > > > > > Cheers, > > > > Grant > > > > > > > > Grant Priestley > > Domain Architect (Analytics) | Coles Financial Services > > > > L1 M12 800 Toorak Road Hawthorn East Victoria 3123 Australia > > T | +61 416 320 936 e | > > grant.priest...@colesfinancialservices.com.au > > > > [image: cid:image001.png@01D04B73.BA61ACB0] > > > > > > >
