Re: confused about DBD implementation of ChopBlanks

Ok, as I suspected, this was sort of my fault. You can indeed do:

$h = DBI->Connect;
$s = $h->prepare(q/select * from sometable/);
$s->{ChopBlanks} = 1;

and it chops blanks but you cannot do:

selectall_arrayref(q/select * from sometable/, {ChopBlanks => 1});

or

prepare(q/select * from sometable/, {ChopBlanks => 1});

Don't know if you should be able to do this but it seems you cannot. I 
think it would be nice especially in the selectall methods as you do not 
see the sth. I tried to locate the code to do this which I thought was 
somewhere under _new_handle (probably dbih_setup_handle) but there is 
magic in there I don't get right now.

Martin

On 03/01/2011 10:52, H.Merijn Brand wrote:
> On Mon, 03 Jan 2011 10:27:52 +0000, "Martin J. Evans"
> <[email protected]>  wrote:
>
>> On 02/01/2011 18:50, H.Merijn Brand wrote:
>>> On Sun, 02 Jan 2011 18:07:13 +0000, "Martin J. Evans"
>>> <[email protected]>   wrote:
>>>
>>>> Sorry if this turns out to be gibberish but I'm been battling with a
>>>> host of unicode problems today and I am quickly losing track.
>>>>
>>>> I can't make ChopBlanks work properly in DBD::ODBC. It works if I use:
>>>>
>>>> $dbh->{ChopBlanks} = 1;
>>>> $sth = $dbh->prepare (q/select * from sometable/);
>>>>
>>>> and does not work if I use:
>>>>
>>>> $sth = $dbh->prepare (q/select * from sometable/);
>>>> $sth->{ChopBlanks} = 1;
>>> The above completely meets my expectation.
>> really. You expect ChopBlanks set directly on an sth to not work?
> Damn :)
> I read that as $dbh->{ChopBlanks} = 1;
>
>>>    Once the sth is created, and
>>> all attributes are set (either directly or derived/inherited from dbh),
>>> they should *not* change when dbh changes it on a higher level.
>> I agree that once set on a sth, a change to the dbh should not change
>> the sth but what I'm seeing is if they are NOT set on the dbh and then
>> you create an sth, you cannot change it on the sth directly. The docs
>> suggest ChopBlanks is for connection and statement handles.
>>
>> $dbh = DBI->connect;
>> $sth = $dbh->prepare (q/select * from sometable/);
>> $sth->{ChopBlanks} = 1
>>
>> now DBIc_has (imp_sth, DBIcf_ChopBlanks) returns false.
> I fully agree that this sounds like unwanted behavior.
>
>>>> and it seems "ChopBlanks = DBIc_has (imp_sth, DBIcf_ChopBlanks);" is not
>>>> true in DBD::ODBC's dbdimp.c.
>>>>
>>>> Various DBD's use DBIc_has (DBD::ODBC, DBD::Pg, DBD::Oracle) or DBIc_is
>>>> (DBD::mysql).
>>> DBD::Unify uses DBIc_has ()
>>> DBD::CSV (through DBD::File) use s DBIc_is ()
>>>
>>> In fact they are the same:
>>>
>>> DBIXS.h:#define DBIc_has(imp,flag) DBIc_is(imp, flag) /* alias for DBIc_is */
>> Should have looked - sorry, I did warn you I'm stuck in a world or pain
>> with unicode right now.
> I know the pain, and I'm not pointing fingers, just passing on info
>
>>>> The DBI::DBD documentation says (for XS):
>>>>
>>>> "Note that you can also obtain standard attributes such as /AutoCommit/
>>>> and /ChopBlanks/ from the attributes parameter, using
>>>> |DBD_ATTRIB_GET_IV| for integer attributes."
>>>>
>>>> and
>>>>
>>>> "The dbd_db_STORE_attrib method
>>>> You do not handle all attributes; on the contrary, you should not handle
>>>> DBI attributes here: leave this to DBI. (There are two exceptions,
>>>> /AutoCommit/ and /ChopBlanks/, which you should care about.)"
>>>>
>>>> I presumed a DBD should "care" about ChopBlanks as DBI is not going to
>>>> remove the trailing blanks not that DBI is not going to store the
>>>> ChopBlanks value and yet when I call DBIc_has(imp_sth, DBIcf_ChopBlanks)
>>>> on a sth it returns false even though I set $sth->{ChopBlanks} = 1.
>>> Before or after the sth was created?
>> Example above, after.
>>
>>>> DBD::ODBC (like all the other DBDs I've checked) does not handle
>>>> ChopBlanks in the STORE or FETCH routines.
>>>>
>>>> Any ideas what is wrong?
>> I may be making a mistake here, and may be ChopBlanks cannot be set on a
>> sth, but in that case the docs are confusing.
> I think it should be possible, at least it would be very DWIMmish
>