sybperl-l Archive

From: "Masatsuyo Takahashi" <freesemt at mail1 dot accsnet dot ne dot jp>
Subject: Re: A patch proposal to the NULL-value problem on blk_rowxfer
Date: Jun 20 2002 3:53PM

Thank you, Gurus Scott, Michael, and Martin, for the appropriate comments
to my proposal.

After reconsidering,  I came to understand the issue more precisely and
realized where I was wrong.

Let me summarize what I have learned.
(I'll ignore the varchar problem here)

First, for undef values, it is natural that the results be

                         null          not null
    --------------------------------
    numeric    (1) NULL   (2) 0
    string        (3) NULL   (4) ""

depending on the attributes of the target column.
And next, for "" values, the results be

                    null              not null
    --------------------------------
    numeric    (5) 0           (6) 0
    string        (7) ""           (8) ""

To summarize,
[Rule1] undef is the only value that is converted to NULL.
[Rule2] defined values are always also defined values in Sybase

You have to be aware of the fact that you get  DEFINED values
(i.e. ""s) when you split a CSV line such as
,,,,,
which doesn't seem to define any values.

Thank you.

Masatsuyo.

----- Original Message -----
From: "Martin Rieder" 
To: "SybPerl Discussion List" 
Sent: Thursday, June 20, 2002 4:29 AM
Subject: Re: A patch proposal to the NULL-value problem on blk_rowxfer


> I was frustrated the first time I encountered this issue with what I
thought
> was undef integer values.  I am OK with the API working as it does and the
> little bit of extra processing to explicitly set NULL value to undef, but
I
> would be in favor adding some words of wisdom to the documentation (maybe
add
> to the sample code) in the appropriate places to help users
understand/avoid
> this issue, especially when dealing with numeric data.
>
> Regards,
> Martin
>
>
> Michael Peppler wrote:
>
> > On Wed, 2002-06-19 at 08:05, Masatsuyo Takahashi wrote:
> > > 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.
> >
> > > 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
> >
> > I agree on the first two. For the last one I have a bit of a problem -
> > and that is related to the never ending argument about empty strings in
> > varchar() columns which end up having a single space (i.e. insert "" to
> > a varchar column will produce " " in the database).
> >
> > Scott's comment that an empty string and a NULL value are different is,
> > in my opinion, relevant.
> >
> > So the question is - should blk_rowxfer() be modified to coerce the
> > empty string to NULL, or should it be the caller's responsibility to
> > make sure that any values where NULL is expected actually have undef,
> > and not the empty string?
> >
> > Personally I tend towards the latter (and maybe Sybase::BLK needs to be
> > modified to properly address this issue?).
> >
> > Anyone else care to comment?
> >
> > (to make things really confusing the behavior could be made
> > configurable...)
> >
> > > Especially, without the "!svp" condition, it may cause memory faults
> > > for 'NA(not assigned)' cases.
> >
> > Yes - absolutely - thanks for catching that!
> >
> > Michael
> > --
> > Michael Peppler / mpeppler@peppler.org / http://www.mbay.net/~mpeppler
> > mpeppler@zetatools.com / ZetaTools, Inc / http://www.zetatools.com
> > ZetaTools: Call perl functions as Sybase stored procedures!
> >
>
  ------------------------------------------------------------------------
> >                        Name: signature.asc
> >    signature.asc       Type: application/pgp-signature
> >                 Description: This is a digitally signed message part
>
>