Add support for querying multiple signals

[krivard]

Fixes cmu-delphi/covidcast-indicators#116

• backwards-compatible signal/signals parameter
• optional 'format' parameter for retrieving results as a tree (preferred by Viz) or as a flat list (backwards-compatible); defaults to flat list
• client support: coffee, js, R, py
• integration tests to check multi-signal queries and queries for tree format

[krivard]

@capnrefsmmat can you check my work in the raw R client? Backwards-compatibility is not something I've had to deal with before in R.

[sgratzl]

looking good, just to clarify: the tree format is

{
  signal1: [...],
  signal2: [...],
}

for me, I would call it more a group by signal. One could do a similar things for every parameter that allows multiple values.

general question: this PR allows me to query multiple signals of the same data source? how about multiple signals distributed in different data sources?

[capnrefsmmat]

The R client change looks fine -- it should support the old syntax and anyone using named arguments. I'm not sure how jsonlite will parse the tree format, but as long as the default format is unchanged from before, current users should not be surprised.

[krivard]

@sgratzl

how about multiple signals distributed in different data sources?

Since we don't enforce unique signal names, what we'd really want for that is to accept (source, signal) pairs, and that's a larger architectural shift than we're really prepared for just now.

[sgratzl]

why not enforcing that a certain character such as : doesn't appear and that you have a combined unique signal id: datasource:signal

[krivard]

That would probably be a fine way to handle it in the clients, but I'm more concerned about the query architecture just now. How important is this to you, should we wait to merge this PR until we get full (source, signal)* support working?

[sgratzl]

as soon as we show small multiples of different signals in production, it will become handy.

[krivard]

Followed up with @sgratzl offline: Small multiples sends 12 API requests (one query per source-signal pair) in the default view, but network time for these queries is less than 10% of the page render time, largely due to browsers parallelizing network requests.

Since small multiples is the major use case for source-signal pairs, and it's not a responsiveness issue, we'll hold off on source-signal pair support for now.

[sgratzl]

another use case which involves more data is when querying for average / count / average cumulative / count cumulative of cases / deaths. since they are all coming from the same data source this PR would save a lot

[krivard]

Yep, that was the original plan for this feature. Once #187 merges we'll apply this one.

…

On Fri, Aug 14, 2020 at 11:59 AM Samuel Gratzl ***@***.***> wrote: another use case which involves more data is when querying for average / count / average cumulative / count cumulative of cases / deaths. since they are all coming from the same data source this PR would save a lot — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#170 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI24CRSKOH5QRUGHMHU3RLSAVNMVANCNFSM4POYLAWA> .

[krivard]

@melange396 check my work on a57b61a? tests pass but I want to make sure there's not a gotcha I didn't see

[melange396]

LGTM!