-
Notifications
You must be signed in to change notification settings - Fork 49
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.T
doesn'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) = true
butNAC(T) = false
. -
PC(T) = true
(orNAC(T) = true
for 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
:T
has no column namedx
. -
1
:T
has a column namedx
but it isn't numeric. -
2
:T
has 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
NAC
constraint. E.g. client requests attributesx
andy
fromT
butT
doesn't have ay
column. Outcome: empty list. - Same as above, but now
T
has bothx
andy
columns withx
numeric andy
non-numeric. Outcome: empty list. - Client requests attributes from multiple tables, none of which
satisfy the
PC
constraint. E.g.x
,y
andz
from tablesT1
andT2
.T1
has bothx
andy
but noz
whereasT2
hasx
andz
but noy
. Outcome: empty list. - Client requests aggregate from multiple tables, none of which
satisfy the
NAC
constraint. E.g. attributesx
andy
,T1
has both buty
isn't numeric whereasT2
has a numericy
but nox
. Outcome: empty list. - Client requests attributes from multiple tables some of which
fail
PC
. E.g. attributex
fromT1
andT2
;T1
has it,T2
does 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
x
is defined both for tablesT1
andT2
but 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