sybperl-l Archive

From: "Scott Zetlan" <scottzetlan at aol dot com>
Subject: RE: A patch proposal to the NULL-value problem on blk_rowxfer
Date: Jun 19 2002 4:32PM

I realize the acceptability issue was addressed to Michael, but I'd like to
jump in anyway, since I've been working on Sybase::BLK.

Sybase treats nulls differently than empty strings.  In fact, logically
speaking, there is a meaningful difference between the statements "I don't
know" and "I know that it's empty."  From a numeric data perspective, it's
important to distinguish between null and 0 -- especially in aggregate
functions like averages.  Because those differences are meaningful, those
utilities which load data into the database must preserve the differences.
Thus Sybase::BLK (and hence blk_rowxfer()) must also distinguish between
those states.

Scott

> -----Original Message-----
> From: owner-SYBPERL-L@list.cren.net
> [mailto:owner-SYBPERL-L@list.cren.net]On Behalf Of Masatsuyo Takahashi
> Sent: Wednesday, June 19, 2002 11:06 AM
> To: SybPerl Discussion List
> Subject: A patch proposal to the NULL-value problem on blk_rowxfer
>
>
> Hi,
>
> I'd like to propose a patch to fix the NULL-value problem on blk_rowxfer
> recently posted by Hiroshi Yamada and answered by Martin Rieder.
>
> I'll clarify the situation first, discuss what to fix, and then show the
> patch.
>
> THE CAUSE OF TROUBLE
>
> The problem comes from the three silmilar but different states
> of an array element, namely,
>
>     (NA) where nothing is assigned yet
>     (UD) where 'undef' has been assigned
>     (NS) where null string '' ha been assigned.
>
> In XS or C level, you can distinguish the above three states as follows.
>
>     if (svp = av_fetch(av, i, 0)) {
>         if(SvOK(*svp)) {
>             if (SvPV(*svp,vlen) && vlen) {
>                 /* non-null string  */
>             } else {
>                 /* NS */
>             }
>         } else {
>             /* UD */
>         }
>     } else {
>         /* NA */
>     }
>
> (I have appended a simple script which verifies this. The script
> uses Inline
> module)
>
>
> WHAT TO FIX
>
> It seems to me that the work-around suggested by Martin is needed
> just because CTlib.xs treats the above three states differently,
> while Perl intends to see them equally.
>
> Thus, I think, in a Perl-like way, it is fair for CTlib.xs to conform to
> Perl.
> That is, all the three states in Perl should be converted within CTlib.xs
> into NULLs in Sybase.
>
>     Perl(XS)    Sybase
>     -----------------
>     NA    =>    NULL
>     UD    =>    NULL
>     NS    =>    NULL
>
>
> ONE POSSIBLE PATCH
>
> If you agree, the patch is simple. It suffices to change only one line
> in CTlib.xs as follows.
>
> Change the line no. 7385 ( if it's sypperl-2.14_01) in blk_rowxfer func
>
>     if (!SvOK(*svp)) {
>
> to
>
>     if (   !svp                        /* not assigned yet  */
>         || !SvOK(*svp)             /* assigned an undef */
>         || SvPV(*svp, slen) && !slen        /* assigned a null string */
>     ) {
>
> I hope this will solve the problem better.
> Especially, without the "!svp" condition, it may cause memory faults
> for 'NA(not assigned)' cases.
>
>
> SMALL ANXIETY
>
> Of the three conversion types, "NS(null string) to NULL" type might
> break some legacy scripts.
>
> But, it seems rare that you don't want columns to be NULLs when there's
> nothing to store.
>
> Is it acceptable, Guru Michael?
>
> Masatsuyo.
> --
> Masatsuyo Takahashi, an adviser to Hiroshi Yamada.
> freesemt@mail1.accsnet.ne.jp
>