[CC'd to dbi-dev as it's of general interest. I trust that's okay.]
On Mon, Feb 23, 2004 at 12:31:51AM -0500, Jeff Urlwin wrote:
>
> > Did you #include dbivport.h and use the new error macros?
>
> Not yet. I was planning on getting to that, but
> a) I wanted to get a release that fixed the stupid makefile.pl bug I
> had. I got tired of the all-too-frequent pings about it
> b) I wanted to get a binary release out for the ActiveState users
> which had an official DBI release instead of a release candidate and thought
> that dbivport.h was part of 1.41 rc ... And didn't see it in 1.40
Fair enough.
> It's on my near term schedulue, though -- maybe even tonight...I'm just
> working on the return &sv_undef/$sth->{NAME} thing first. dbivport.h will
> be next, since it's a compatibility thing :) Did you have in mind that we'd
> copy it during Makefile.PL run? If so, shouldn't you just include it in
> DBD::postamble? Patches welcome? :)
No. The idea is that you include the latest in your releases so that
they can be built with older DBI's. That way your code can use the new
DBIc_SET_ERR_CHAR even when it's built against much older DBIs.
> Getting back to the issue when I return &sv_undef from my
> dbd_st_FETCH_attrib(), I think it's in DBI.xs. What I see is that newAV()
> is called, then later used by valuesv = newRV(sv_2mortal( (av ? (SV *)av :
> (SV *)hv) )); My fix would be to check for &sv_undef returned and let that
> continue.
DBI 1.41 RC2 has changed the code so NAME_(uc|lc), NAME_hash, NAME_(uc|lc)_hash
will all be undef if NAME does not return a ref.
/* deal with: NAME_(uc|lc), NAME_hash, NAME_(uc|lc)_hash */
...
svp = hv_fetch((HV*)DBIc_MY_H(imp_sth), "NAME",4, FALSE);
sv = (svp) ? *svp : &sv_undef;
if (SvGMAGICAL(sv)) /* call FETCH via magic */
mg_get(sv);
if (SvROK(sv)) {
Also fetching NAME TYPE SCALE etc via DBIc_DBISTATE(imp_sth)->get_attr(sth, keysv);
is no longer a fatal error. The attributes are now 'known' and just return undef.
> However, I have some issues with that -- and they may only be
> mine. The cacheing is not working on this and due to the way I've
> implemented DBD::ODBC and SQLMoreResults(). My first call to my
> dbd_describe() fails miserably in my test case. But the second time
> through, it doesn't because I've called SQLMoreResults() and dbd_describe
> acts as if there is no result set (num_fields == 0). So, the second time
> around, I get an empty array. I would have to re-design the code a bit to
> handle that and am a bit hesitant to do that since I worked the behavior
> through at length a while ago to 'do what makes sense' for at least some
> conditions. This is one of the edge cases.
>
> Is it OK to move forward with an empty array, or would you strongly prefer
> the null reference?
undef.
Also, I'd like DBI v2 to have an official method to 'reset' a statement
handle back to its virgin state so that an official more_results() method
can be added.
I think DBD::ODBC and DBD::Sybase have this already. DBD::Pg may do.
DBD::mysql is going to need it etc etc. So the DBI needs to support it
so it's done consistently and to make life easier for future driver authors.
I'd appreciate it if all driver authors who have written such code to send
(just) me a copy of the function so I can get an idea what you're all doing.
Thanks.
Tim.
