The semantics of
null+42 in SQL is
This may or may not be a concern depending on how the application is written
or what it is trying to do.
SQL Frames provides scripted fields which are compiled and then evaluated
against each row. SQL Frames also provides the ability to generate
SQL based on the data transformation logic used to create the DataFrame.
If one were to freely move the computation of expressions between server and client
as desired end users would expect the results to be same. That is why the
When evaluting a script, it is possible to provide different
null semantics as outlined
All check - in this mode, if a script field uses, say, 3 fields, then all three field values are checked (for the given row) and if any of them is null, then that
nullvalue is returned. The downside of this is, if the user has a conditional logic that avoided accessing the
nullvalue the result will be something other than a
Access check - in this mode, a value is checked for
nullonly checked when it is accessed and not at the beginning of evaluating the script. Upon access, the entire expression becomes
null. This provides some of the semantics of SQL but not all.
Usage based check - While the above avoids returning
nullwhen a value is not accessed, sometimes even if the value is accessed and determined to be null, user might do something else. For example, using
NULLIFtype of functions it is possible to detect for null and then use something else in place of them.
NULLIF(x,42)for example evalutes to 42 if
xis null. With the *Access check mode, this will not work because as soon as the value of x is accessed, it evaluates to
nullwithout regards to the rest of the computation such as the
Usage based check assumes that the user is writing the script explicitly do the check
which actually is same as No check. Of course, the ideal case would be that the script context
provides information on when to make the expression evaluate to
null based on accessing a
vs when to let the script to use the
null value and do something with it.