-
Notifications
You must be signed in to change notification settings - Fork 52
Success and Failure Scenarios
The model makes it plain that the query method comes with (implicit)
preconditions PC and NAC—the latter only applicable to the case
where the client requested a numeric aggregate, one of sum, avg,
min, or max. If such preconditions fail, the client gets back either
an empty list or an incomplete result list. Otherwise, preconditions
hold and the client gets back a list containing the rows each table
contributed to the query—in particular, this could be the empty list
again if the query returned an empty result list on each table. We're
going to flesh out how the possible combinations of PC and NAC
determine success and failure scenarios.
As a warm up, let's start with the case where the query only involves
a single table T. We return an empty list in any of these cases:
-
PC(T) = false, i.e.Tdoesn't have some of the requested attributes. - The client requested a numeric aggregate (
sum,avg,min,max) but some of the requested attributes aren't numeric, i.e.PC(T) = truebutNAC(T) = false. -
PC(T) = true(orNAC(T) = truefor the numeric aggregate case) but the query predicate selects no rows, i.e. there actually are no matching records.
The first two are failure scenarios whereas the last one is a success
scenario. The only other possible success scenario is when PC(T) = true
(or NAC(T) = true) and the query selects some rows in which case
the client gets back a non-empty result list.
What happens if the query touches more than one table? The situation
is conceptually similar to the single-table case but there's a combinatorial
explosion of scenarios. How many? 3^a⋅t where a is the number of
requested attributes and t is the number of tables. To see why,
we'll need a little combinatorics with which we can handle both the
single- and multi-table case.
Any requested attribute x can be in one of three states with respect
to a table T
-
0:Thas no column namedx. -
1:Thas a column namedxbut it isn't numeric. -
2:Thas a numeric column namedx.
We can build a chart TA to represent all possible states of the
requested attributes Attr = { x, y, ...} with respect to T
x y ...
--- --- ---
0 0 ...
0 1 ...
0 2 ...
1 0 ...
... ... ...
2 2 ...
Obviously
TA = {0, 1, 2} × {0, 1, 2} × ... = {0, 1, 2}^a
where a = |Attr|, the number of requested attributes. Now if T1,
T2, ..., are the tables touched by the query, we'll have to look at
V = TA1 × TA2 × ...
to determine all possible scenarios, of which there are 3^a⋅t where
t is the number of tables. In other words, we identify each possible
scenario with a "scenario" vector v ∈ V. With that in mind, if the
client requests no numeric aggregate operation, the success scenarios
and failure scenarios are, respectively, the sets S1 and F1
S1 = { v ∈ V | ∀ i . 0 < v[i] }
F1 = V - S1 = { v ∈ V | ∃ i . v[i] = 0 }
If the client requested a numeric aggregate operation, success and failure sets are
S2 = { v ∈ V | ∀ i . v[i] = 3 }
F2 = V - S2 = { v ∈ V | ∃ i . v[i] < 3 }
Notice that if there's only one table involved, the query method
returns an empty list in failure scenarios whereas if multiple tables
get queried, on failure the query method returns either an empty
list (preconditions failed on all tables) or a list with results from
some of the tables (preconditions failed only on some tables, other
tables contributed results).
Here are a few concrete examples of failure scenarios.
- Client requests numeric aggregate from one table that doesn't
satisfy the
NACconstraint. E.g. client requests attributesxandyfromTbutTdoesn't have aycolumn. Outcome: empty list. - Same as above, but now
Thas bothxandycolumns withxnumeric andynon-numeric. Outcome: empty list. - Client requests attributes from multiple tables, none of which
satisfy the
PCconstraint. E.g.x,yandzfrom tablesT1andT2.T1has bothxandybut nozwhereasT2hasxandzbut noy. Outcome: empty list. - Client requests aggregate from multiple tables, none of which
satisfy the
NACconstraint. E.g. attributesxandy,T1has both butyisn't numeric whereasT2has a numericybut nox. Outcome: empty list. - Client requests attributes from multiple tables some of which
fail
PC. E.g. attributexfromT1andT2;T1has it,T2does not. Outcome: results from tables satisfyingPC.
The examples also highlight that in general, the set of failed attributes
for one table may be different than another. Moreover, in the case of
aggregates, some attributes may have failed PC whereas others NAC.
For the sake of completeness, here's an example of success scenario:
- Client requests existing attributes but there are no matching
records. E.g. attribute
xis defined both for tablesT1andT2but none of them contributes rows to the query. Outcome: empty list.
Developer Track
- Cookbook
- Gauging performance
- Mother of all queries
- Enteater
- Work a Q
- No async free lunch
- Release procedure
User Track