Merge TimeSeriesQueries.jl into TimeSeries

[milktrader]

The TimeSeriesQueries unregistered package provides SQL-like query syntax of TimeSeries TimeArray objects. Passing tests and documentation are complete.

Here is a quick screencast

[femtotrader]

When #292 will be closed It should be possible to use https://github.com/davidanthoff/Query.jl

[milktrader]

I don't think so but if you find Query.jl supports TimeArrays please advise with an example.

[ararslan]

cc @davidanthoff

[davidanthoff]

You can now query TimeArrays with Query.jl, and also materialize query results into a TimeArray. Here are some examples:

using Query, TimeSeries, DataFrames

dates  = collect(Date(1999,1,1):Date(2000,12,31))
mytime = TimeArray(dates, rand(length(dates)))

df = @from i in mytime begin
    @group i.value by year(i.timestamp) into g
    @select {Year=g.key, Average=mean(g)}
    @collect DataFrame
end

If your final @select statement creates something that can be turned into a TimeArray (i.e. it has a timestamp column, and all the other columns need to have the same type), you can also materialize things into a TimeArray:

ta = @from i in mytime begin                              
    @group i.value by year(i.timestamp) into g           
    @select {timestamp=Date(g.key,1,1), average=mean(g)} 
    @collect TimeArray                                   
end                                  

I'll also add another way to materialize into a TimeArray soon, see queryverse/IterableTables.jl#27. With that you will no longer have to create a timestamp column in the query.

All of this comes as a side-effect of IterableTables.jl, which enables a whole bunch of other scenarios for TimeArray as well: you can convert it into lots of other table types, you can convert from lots of other table types (as long as the source table has a timestamp column and all the other columns are of one type) and you can use TimeArrays with things like Gadfly, VegaLite, GLM etc.

Any feedback is welcome!

[davidanthoff]

Oh, one last thing: the implementation for the TimeArray sink is terrible right now, so that is known to be slow and I'll fix it at some point (queryverse/IterableTables.jl#11). That should only affect anything that creates a TimeArray, querying one should not be affected by this.