You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any instance of it holds a reference to the evaluated WHERE clause via the whereString. So, for example,
val emailContains =Fields.Email.Address contains "veronica"
At this point, the WHERE clause has already been evaluated to something like (pseudocode to keep things simple),
Where {
whereString ="address LIKE 'veronica'"
}
If we redact the entire whereString, it will evaluate to...
"***********************"
This certainly does uphold privacy laws but it doesn't help us debug the issues in production when we look at logs from crashes or analytics. Furthermore, this will just produce an exception when executing the query 😓
Then comes the question, how do we maintain the WHERE clause structure and integrity? How can we redact only "veronica" from this raw String?
Solution
Lazily evaluate the the WHERE clause. In the above example, the ideal output would be...
"address LIKE '********'"
The redaction will be done in #147. This issue simply enables that.
This will require us to refactor the Where class to hold a reference to the actual left-hand-side, operator, and right-hand-side values. Then lazily evaluate (combined) them when toString is invoked.
So, something like this...
data classWhere<outT:Field> (
privatevallhs:LeftHandSide<T>,
privatevaloperator: Operator,
privatevalrhs:RightHandSide<T>
) {
privateval evaluatedWhereString:String by unsafeLazy {
"$lhs$operator$rhs"
}
overridefuntoString(): String= evaluatedWhereString
}
/** * Each element in a where statement has the structure; LHS OPERATOR RHS. * * The left hand side (lhs) can either be another where element OR it can be a field.*/internalsealedinterfaceLeftHandSide<outT> {
classWhereHolder<outT:Field>(valwhere:Where<T>) : LeftHandSide<T>
classFieldHolder<outT:Field>(valfield:T) : LeftHandSide<T>
}
/** * Each element in a where statement has the structure; LHS OPERATOR RHS. * * The right hand side (rhs) can either be another where element OR it can be any value.*/internalsealedinterfaceRightHandSide<outT> {
classWhereHolder<outT:Field>(valwhere:Where<T>) : RightHandSide<T>
classValueHolder<outT:Field>(valvalue:Any) : RightHandSide<T>
}
/** * Each element in a where statement has the structure; LHS OPERATOR RHS. * * The operator is an SQL operator.*/internalenumclassOperator(valoperator: String) {
AND("AND"),
OR("OR"),
EQUAL("="),
NOT_EQUAL("!="),
GREATER_THAN(">"),
GREATER_THAN_OR_EQUAL(">="),
LESS_THAN("<"),
LESS_THAN_OR_EQUAL("<="),
IS("IS"),
IS_NOT("IS NOT"),
IN("IN"),
NOT_IN("NOT IN"),
LIKE("LIKE"),
NOT_LIKE("NOT LIKE")
}
The text was updated successfully, but these errors were encountered:
In order to complete #147 and fix #142, the
Where
statement needs to be lazily evaluated so that it can retain typed information that can be mutated.Problem
Currently,
Where
is defined as...Any instance of it holds a reference to the evaluated WHERE clause via the
whereString
. So, for example,At this point, the WHERE clause has already been evaluated to something like (pseudocode to keep things simple),
If we redact the entire
whereString
, it will evaluate to..."***********************"
This certainly does uphold privacy laws but it doesn't help us debug the issues in production when we look at logs from crashes or analytics. Furthermore, this will just produce an exception when executing the query 😓
Then comes the question, how do we maintain the WHERE clause structure and integrity? How can we redact only "veronica" from this raw String?
Solution
Lazily evaluate the the WHERE clause. In the above example, the ideal output would be...
"address LIKE '********'"
The redaction will be done in #147. This issue simply enables that.
This will require us to refactor the
Where
class to hold a reference to the actual left-hand-side, operator, and right-hand-side values. Then lazily evaluate (combined) them whentoString
is invoked.So, something like this...
The text was updated successfully, but these errors were encountered: