On Thu, Sep 29, 2016 at 11:30:08PM -0000, Greg Sabino Mullane wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> > Should a call to prepare() return an Active statement? (i.e. $sth->{Active}
> > == 1)
> >
> > This appears to be the behaviour of DBD::Sybase, but not DBD::Pg
>
> I don't think there is a canonical answer to that, but I can say that
> DBD::Pg in most cases will not even talk to the server until the first
> execute() after the prepare(), so it not being Active seems a sane
> interpretation.
> The docs for DBD::Pg:
>
> Indicates if a handle is active or not. For database handles, this
> indicates if the database has been disconnected or not. For statement
> handles, it indicates if all the data has been fetched yet or not.
> Use of this attribute is not encouraged.
>
> As far as I can tell, DBD::Sybase makes not effort to do anything special
> regarding that attribute.
DBD::Sybase has this
/* Re-enable the active flag here (in 1.05_03) to fix bug with
finish not getting called correctly */
DBIc_ACTIVE_on(imp_sth);
at the end of syb_st_prepare() in dbdimp.c
So, it explictly sets Active to deal with some issue that I haven't
fully delved into.
> In short, I would not rely upon it, especially across DBDs.
That's unfortunate, because Class::DBI does.
$ grep -r Active .
./lib/Class/DBI.pm: $sth->execute(@$args) unless $sth->{Active};
(from sth_to_objects)
As far as I can see, this is to work out whether the sth that's been
passed in has already had execute called on it (e.g. part of a multiple
result loop). Removing the $sth->{Active} check (and ensuring Ima::DBI
always calls prepare and not prepare_cached (I haven't figured out what's
going on there yet) gets Class::DBI working with DBD::Sybase.
Our current code overrides db_Main which seems like an unnecessary hack
to me, and confuses Class::DBI somewhat, triggering warnings.
I'm halfway down this rabbit hole and not really sure which turning to
take now!
--
Russell Howe
[email protected]
