"Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:
> From Roxen 5.0:
> // Change in >= 5.0: Don't abuse RXML.nil for SQL NULL. RXML.nil
> // means UNDEFINED in this context, i.e. that the variable
> // doesn't exist at all. An SQL NULL otoh is just a special
> // value in an existing variable, at least on the RXML level.
>
> Pike 7.8 returns Pike UNDEFINED objects in Sql.Sql queries for columns
> that return NULL values (as opposed to integer zero); Pike <7.8 returned
> integer zeros.
On the pike level the interface isn't ambiguous as it was on the RXML
level, since all other values are returned as strings. It's therefore
not a problem returning either a normal zero or UNDEFINED for an sql
NULL.
Therefore I don't really see the point with the change in 7.8. Note
also that a mapping cannot carry UNDEFINED as a value for natural
reasons, so in Sql.query() those UNDEFINED's still becomes normal
zeroes.
The fact that all non-NULL values are returned as strings is another
problem in the Sql module, but it does avoid this particular problem.
If a better API is added to it, where integers are returned as ints
etc, then there should be an SqlNull object there too for sql NULLs.
Using UNDEFINED for it would be abuse (see below). (Further
discussions about this should go to the pike dev list.)
> Now, with this new sql_null object, things get a bit messy.
> How am I supposed to distinguish a zero value from a NULL inside RXML
> now?
As you noticed in your followup, the sql_null is nearly identical to
RXML.nil, so it should still work pretty much as usual. The new <if
variable-exists> test will correctly tell you that the variable exists
when it contains an sql NULL value. That wasn't possible earlier.
> What's wrong with simply setting the RXML variable to Pike UNDEFINED
> as well (in case of a NULL value)?
I think the comment you quoted says pretty clearly what's wrong with
that. An sql NULL is a real value in sql-land - it can be assigned to
columns and read back etc. UNDEFINED is not like that; it's a
transient value that indicates the _lack_ of a value in the queried
container, and it intrinsically cannot be stored reliably everywhere.
The corresponding thing in sql is that a response lacks a field
altogether. E.g. if a "SELECT * FROM ..." returned the fields "foo"
and "bar" then it'd be correct to return UNDEFINED if the field "zonk"
is queried in the response, as opposed to querying the existing "foo".
That's true even if "foo" contains NULL - a NULL value doesn't make
the "foo" field disappear. Using UNDEFINED for both would require that
the user knows out-of-band which fields the response should contain.
Often it is known, but not necessarily in cases like "SELECT *".
> Nonetheless, in order for the SQL glue of Roxen to work as intended,
> it needs to be altered slightly, it misinterprets the zero-int return
> values from the Sql lib.
Those changes shouldn't be necessary since all non-null values are
strings. If your sql glue does something else then it doesn't adhere
to the Sql module API.
Btw, I wouldn't call the UNDEFINED value in pike an object. It's not,
and it'd be a bit misleading to think of it as one.
|