RE: ANNOUNCE: DBD::Oracle 1.15
> Added $dbh->{ora_parse_error_offset} attribute
Attached: some POD for the attribute above (I should have included this with
the patch for the attribute), and also for the reauthenticate private func
since it's undocumented.
ta,
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
/
DBD-Oracle-1.15-pod.patch
Description: Binary data
Re: DBD::Mock
Tim Bunce wrote:
On Fri, Jan 30, 2004 at 12:27:02PM -0700, jim cromie wrote:
Tim Bunce wrote:
On Fri, Jan 30, 2004 at 03:00:37AM -0700, jim cromie wrote:
This sounds like it could plug into the trace mechanism, either
increasing its
leverage, simplifying its implementation, or both.
I've long wanted the DBI to have code hooks for method call entry & exit
that could be used for building all sorts of funky tools.
And having just crept up to a line, let me cross it. Can new DBI2 have
2 logging levels under transactions ? Anything that commits (success)
logs at 1 or 2, things that rollback are logged at 5 or 6. This should
help unravel anomalous behavior by automatically putting your fovea
on it.
speculative logging: The basic idea is to buffer up a log as a
transaction proceeds,
and decide afterwards what details of the log you want to keep - ie emit
to the logging device.
Commit/rollback is the most obvious decision point, if youve got a
rollback, or an error, dump the log-trace since the start-transaction at
a high level of detail, if all went smoothly, log only at a low trace-level.
Ah, okay. No, I wouldn't add that to the DBI, but if I add hooks
for method call entry & exit that could be used to implement what
you want - but do it for all drivers.
It seems that all tracing/logging activity could be implemented by these
hooks.
assuming DBI dispatch is done by AUTOLOAD, (for sake of discussion)
sub AUTOLOAD {
# call entry hooks
$_->(@_) foreach ($callbacks{"${AUTOLOAD}_entry"});
# call method itself, whether its on $dbh, $drh, etc..
@res = $AUTOLOAD->(@_);
# call post hooks
$_->([EMAIL PROTECTED], [EMAIL PROTECTED]) foreach $callbacks{"${AUTOLOAD}_exit"});
}
and trace() just controls those callback lists kept for each hook.
(That reminds me, anothet component is to allow tracing to a
filehandle so a tied handle can be used, for example to gether trace
output into a string.)
there seems (to me anyway) some advantage to treating each
trace/set_error/info item separately. If autoflush on the handle can be
turned off,
theres some possiblity of subclassing, and filtering the items when the
queue is committed
to the file/socket/logging-object.
having named callbacks might be better than in an array, so that the
trace-cb
is easy to replace wo disturbing info-cb, error-cb, etc..
But I confess, im not sure anymore whether were talking dbi-2 or 1 now.
Tim.
.
Re: DBI source code under perforce soon
On Jan 30, 2004, at 2:15 PM, Tim Bunce wrote: If you want to be sent email whenever the DBI source code is changed, send an email to [EMAIL PROTECTED] in order to subscribe to the dbi-changes mailing list. I thought it was going to be Subversion David
Re: DBD::Mock
On Fri, Jan 30, 2004 at 12:27:02PM -0700, jim cromie wrote: > Tim Bunce wrote: > > >On Fri, Jan 30, 2004 at 03:00:37AM -0700, jim cromie wrote: > > > >>This sounds like it could plug into the trace mechanism, either > >>increasing its > >>leverage, simplifying its implementation, or both. > > > >I've long wanted the DBI to have code hooks for method call entry & exit > >that could be used for building all sorts of funky tools. > > > >>And having just crept up to a line, let me cross it. Can new DBI2 have > >>2 logging levels under transactions ? Anything that commits (success) > >>logs at 1 or 2, things that rollback are logged at 5 or 6. This should > >>help unravel anomalous behavior by automatically putting your fovea > >>on it. > > speculative logging: The basic idea is to buffer up a log as a > transaction proceeds, > and decide afterwards what details of the log you want to keep - ie emit > to the logging device. > > Commit/rollback is the most obvious decision point, if youve got a > rollback, or an error, dump the log-trace since the start-transaction at > a high level of detail, if all went smoothly, log only at a low trace-level. Ah, okay. No, I wouldn't add that to the DBI, but if I add hooks for method call entry & exit that could be used to implement what you want - but do it for all drivers. (That reminds me, anothet component is to allow tracing to a filehandle so a tied handle can be used, for example to gether trace output into a string.) Tim.
DBI source code under perforce soon
If you want to be sent email whenever the DBI source code is changed, send an email to [EMAIL PROTECTED] in order to subscribe to the dbi-changes mailing list. Tim.
Re: Patch to stop printing password on stderr
Thanks applied.
Tim.
On Fri, Jan 30, 2004 at 03:09:42PM -, Avis, Ed wrote:
> This patch stops DBI printing the connection password in an error
> message.
>
> diff -ru DBI-1.40/DBI.pm DBI-1.40-new/DBI.pm
> --- DBI-1.40/DBI.pm 2004-01-08 14:03:57.0 +
> +++ DBI-1.40-new/DBI.pm 2004-01-30 14:54:52.0 +
> @@ -532,7 +532,7 @@
>
> # Set $driver. Old style driver, if specified, overrides new dsn style.
> $driver = $old_driver || $1 || $ENV{DBI_DRIVER}
> - or Carp::croak("Can't connect(@_), no database driver specified "
> + or Carp::croak("Can't connect to data source $dsn, no database driver
> specified "
> ."and DBI_DSN env var not set");
>
> if ($ENV{DBI_AUTOPROXY} && $driver ne 'Proxy' && $driver ne 'Sponge' && $driver
> ne 'Switch') {
>
>
> --
> Ed Avis <[EMAIL PROTECTED]>
Re: DBD::Mock
Tim Bunce wrote:
On Fri, Jan 30, 2004 at 03:00:37AM -0700, jim cromie wrote:
This sounds like it could plug into the trace mechanism, either
increasing its
leverage, simplifying its implementation, or both.
I've long wanted the DBI to have code hooks for method call entry & exit
that could be used for building all sorts of funky tools.
And having just crept up to a line, let me cross it. Can new DBI2 have
2 logging levels under transactions ? Anything that commits (success)
logs at 1 or 2, things that rollback are logged at 5 or 6. This should
help unravel anomalous behavior by automatically putting your fovea
on it.
I'm not quite sure what you're asking for there.
Tim.
sorry, I could have been clearer. esp exersizing new vocabulary.
speculative logging: The basic idea is to buffer up a log as a
transaction proceeds,
and decide afterwards what details of the log you want to keep - ie emit
to the
logging device.
Commit/rollback is the most obvious decision point, if youve got a
rollback, or an error, dump the log-trace since the start-transaction at
a high
level of detail, if all went smoothly, log only at a low trace-level.
Another way of looking at this is helping trace() to work in a scoped
manner,
perhaps even as attributes to handles, etc.
trace"
DBI->trace($trace_level)
DBI->trace($trace_level, $trace_filename)
$dbh->trace({on_success => 1, on_err => 6 });
$sth->trace('+1')
$sth->trace({filter => sub {...})
Id hope that scoped detail-control might help find the origin of
an error caught at $sth->execute(),
causing a detailed dump from beginning of the scope,
whether its a transaction, perl-method, handle, etc.
wrt vocabulary, webmd.com showed me this:
*The *macula*.* This is the bull's-eye at the center of the retina. The
dead center of this bull's eye is called the *fovea*. Because it's at
the focal point of the eye, it has more specialized, light sensitive
nerve endings, called photoreceptors, than any other part of the retina.
The fovea is where the eye is most capable of 'grokking' the scene. A large
part of the visual cortex is dedicated to processing the image collected
by the
fovea.
With this, the log contained that detail where it counted, with the
surrouinding
log entries providing context at a summary level.
Re: DBD-Oracle and XMLType
On Fri, Jan 30, 2004 at 03:01:03PM +0100, Hendrik Fuss wrote: > > > The attached patch (based on DBD-Oracle 1.15) enables you to upload > > > XMLType objects (OCIXMLTypePtr) by binding them as SQLT_NTY. In dbdimp.c > > > I added a function dbd_rebind_ph_nty for that purpose. You need to > > > create that XMLType object first using the C function > > > createxmlfromstring in xml.c. > > > > I there any chance you could post that as a context diff (diff -u ideally > > or else diff -c)? It's much safer and more useful. Thanks. > > Good idea. Here's a diff -u of dbdimp.c. Thanks. > By the way: I have thougt about general support of named types, not just > XMLType, but you need to get the type description (TDO) from somewhere. > My code just checks if the perl variable is a blessed reference of > "OCIXMLTypePtr". Doing the equivalent of m/^OCI(\w+)Ptr$/ and then calling OCITypeByName with $1 uppercased might take us (or someone) a step further. > Also note that my code can't handle downloading of XMLType objects yet. I'll trust that some kind soul with an itch will send a patch :-) Thanks again Hendrik. Tim.
Patch to stop printing password on stderr
This patch stops DBI printing the connection password in an error
message.
diff -ru DBI-1.40/DBI.pm DBI-1.40-new/DBI.pm
--- DBI-1.40/DBI.pm 2004-01-08 14:03:57.0 +
+++ DBI-1.40-new/DBI.pm 2004-01-30 14:54:52.0 +
@@ -532,7 +532,7 @@
# Set $driver. Old style driver, if specified, overrides new dsn style.
$driver = $old_driver || $1 || $ENV{DBI_DRIVER}
- or Carp::croak("Can't connect(@_), no database driver specified "
+ or Carp::croak("Can't connect to data source $dsn, no database driver
specified "
."and DBI_DSN env var not set");
if ($ENV{DBI_AUTOPROXY} && $driver ne 'Proxy' && $driver ne 'Sponge' && $driver
ne 'Switch') {
--
Ed Avis <[EMAIL PROTECTED]>
Re: DBD-Oracle and XMLType
On Fri, Jan 30, 2004 at 11:41:31AM +0100, Hendrik Fuss wrote:
> Hi everyone,
>
> It's been a while since I last posted here. In September 2003 I was
> trying to add support for binding XMLType objects to DBD-Oracle, so that
> you could easily insert large (ie >4k) XML data into an XMLType table.
>
> Unfortunately my employer fired me in October 2003 and in the remaining
> time I had to work on other projects, so I wasn't able to complete the
> DBD project. Since I won't have access to an oracle database from now
> on, I thought the least I can do is to provide my code as it is to the
> list. Blame German economy. :-(
I'm sorry to hear that Hendrik.
> The attached patch (based on DBD-Oracle 1.15) enables you to upload
> XMLType objects (OCIXMLTypePtr) by binding them as SQLT_NTY. In dbdimp.c
> I added a function dbd_rebind_ph_nty for that purpose. You need to
> create that XMLType object first using the C function
> createxmlfromstring in xml.c.
I there any chance you could post that as a context diff (diff -u ideally
or else diff -c)? It's much safer and more useful. Thanks.
> my $xml = createxml($dbh, 'Test document');
> my $sth = $dbh->prepare('INSERT INTO xml_type VALUES (?)');
> $sth->bind_param(1, $xml, { ora_type => 108 }); # SQLT_NTY
> $sth->execute();
Great.
> Please note that this code is really just early development, which I
> wouldn't publish under normal circumstances. :) I just hope it might me
> useful to someone.
It will. I'll add it in and let others polish it :)
> Well then, time to say goodbye
> thanks to Tim and everyone who contributed to dbi for a great piece of
> software
Thanks Hendrik. And thank you for your contribution. Many people
have asked for named type support. It's great to be able to get
such a good kick start with the code.
Good luck.
Tim.
Re: DBD::Mock
On Fri, Jan 30, 2004 at 03:00:37AM -0700, jim cromie wrote: > > This sounds like it could plug into the trace mechanism, either > increasing its > leverage, simplifying its implementation, or both. I've long wanted the DBI to have code hooks for method call entry & exit that could be used for building all sorts of funky tools. > And having just crept up to a line, let me cross it. Can new DBI2 have > 2 logging levels under transactions ? Anything that commits (success) > logs at 1 or 2, things that rollback are logged at 5 or 6. This should > help unravel anomalous behavior by automatically putting your fovea > on it. I'm not quite sure what you're asking for there. Tim.
DBD-Oracle and XMLType
Hi everyone,
It's been a while since I last posted here. In September 2003 I was
trying to add support for binding XMLType objects to DBD-Oracle, so that
you could easily insert large (ie >4k) XML data into an XMLType table.
Unfortunately my employer fired me in October 2003 and in the remaining
time I had to work on other projects, so I wasn't able to complete the
DBD project. Since I won't have access to an oracle database from now
on, I thought the least I can do is to provide my code as it is to the
list. Blame German economy. :-(
The attached patch (based on DBD-Oracle 1.15) enables you to upload
XMLType objects (OCIXMLTypePtr) by binding them as SQLT_NTY. In dbdimp.c
I added a function dbd_rebind_ph_nty for that purpose. You need to
create that XMLType object first using the C function
createxmlfromstring in xml.c.
The XMLType object is either created from an OCIString or from a
temporary CLOB depending on the length of the source string. Have a look
at the bottom of ociap.h, all the (undocumented) XMLType functions are
there, and there are also some constants in oci.h.
I'm not sure if the CLOB code currently works.
Here is another code fragment:
my $xml = createxml($dbh, 'Test document');
my $sth = $dbh->prepare('INSERT INTO xml_type VALUES (?)');
$sth->bind_param(1, $xml, { ora_type => 108 }); # SQLT_NTY
$sth->execute();
Please note that this code is really just early development, which I
wouldn't publish under normal circumstances. :) I just hope it might me
useful to someone.
Well then, time to say goodbye
thanks to Tim and everyone who contributed to dbi for a great piece of
software
Cheers,
Hendrik
--
hendrik fuß
morphochem AG
gmunder str. 37-37a
81379 muenchen
tel. ++49-89-78005-0
fax ++49-89-78005-555
[EMAIL PROTECTED]
http://www.morphochem.de
151a152
> case 108: /* SQLT_NTY */
992a994,996
> case SQL_UDT:
> return 108; /* Oracle NTY */
>
1004a1009,1072
> static int
> dbd_rebind_ph_nty(sth, imp_sth, phs)
> SV* sth;
> imp_sth_t *imp_sth;
> phs_t *phs;
> {
> OCIType *tdo = NULL;
> sword status;
> SV* ptr;
>
> if (phs->is_inout)
> croak("OUT binding for NTY is currently unsupported");
>
> /* ensure that the value is a support named object type */
> /* (currently only OCIXMLType*) */
> if ( sv_isa(phs->sv, "OCIXMLTypePtr") ) {
> OCITypeByName(imp_sth->envhp, imp_sth->errhp, imp_sth->svchp,
> (CONST text*)"SYS", 3,
> (CONST text*)"XMLTYPE", 7,
> (CONST text*)0, 0,
> OCI_DURATION_CALLOUT, OCI_TYPEGET_HEADER,
> &tdo);
>
> ptr = SvRV(phs->sv);
> phs->progv = (void*) SvIV(ptr);
> phs->maxlen = sizeof(OCIXMLType*);
> }
> else
> croak("Unsupported named object type for bind parameter");
>
>
> /* bind by name */
>
> OCIBindByName_log_stat(imp_sth->stmhp, &phs->bndhp, imp_sth->errhp,
> (text*)phs->name, (sb4)strlen(phs->name),
> (dvoid *) NULL, /* value supplied in BindObject later */
> 0,
> (ub2)phs->ftype, 0,
> NULL,
> 0, 0,
> NULL,
> (ub4)OCI_DEFAULT,
> status
> );
>
> if (status != OCI_SUCCESS) {
> oci_error(sth, imp_sth->errhp, status, "OCIBindByName SQLT_NTY");
> return 0;
> }
> if (DBIS->debug >= 3)
> PerlIO_printf(DBILOGFP, "pp_rebind_ph_nty: END\n");
>
>
> /* bind the object */
>
> OCIBindObject(phs->bndhp, imp_sth->errhp,
> (CONST OCIType*)tdo,
> (dvoid **)&phs->progv,
> (ub4*)NULL,
> (dvoid **)NULL,
> (ub4*)NULL);
>
> return 2;
> }
1309a1378,1380
> case 108:
> done = dbd_rebind_ph_nty(sth, imp_sth, phs);
> break;
1331c1403
< int at_exec = (phs->desc_h == NULL);
---
> int at_exec = (phs->desc_h == NULL) && (phs->ftype != 108);
1419c1491
< if (SvROK(newvalue) && !IS_DBI_HANDLE(newvalue))
---
> if (SvROK(newvalue) && (!IS_DBI_HANDLE(newvalue)) && (sql_type!=SQLT_NTY))
1420a1493
> /* ref allowed for OCIXMLType* */
2219a2293
> case SQLT_NTY: sql_fbh.dbtype = SQL_UDT; break;
#include "oci.h"
#include
/* This helper function creates an XMLType object from a string source.
*
* The resulting object can be bound to a placeholder, if ora_type =>
* SQLT_NTY is specified.
*/
static void checkerr(errhp, status)
OCIError *errhp;
sword status;
{
text errbuf[512];
ub4 buflen;
sb4 errcode;
switch (status)
{
case OCI_SUCCESS:
break;
case OCI_SUCCESS_WITH_INFO:
printf("Error - OCI_SUCCESS_WITH_INFO\n");
break;
c
Error
The message contains Unicode characters and has been sent as a binary attachment. <>
Re: DBD::Mock
Chris Winters wrote: A few weeks ago I posted a message about a mock DBD and got the response from Tim that DBD::NullP (included in the DBI dist) would be a good place to start. I built on that (but far too much for a patch, sorry Tim) and created DBD::Mock, which does everything I need so far. It contains everything in a single .pm file to make it easy to ship with your distribution for testing. I plan to make it available on CPAN as well. The docs so far are below. Comments welcome, even if they're of the "dumbest thing I've ever seen" variety :-) Chris NAME DBD::Mock - Mock database driver for testing this is very cool. seems to relate strongly to : "Conformance test script for drivers" On Sat 17 Jan 2004 15:16, Tim Bunce <[EMAIL PROTECTED]> wrote: On Fri, Jan 16, 2004 at 07:48:15PM -0500, Thomas A. Lowery wrote: > > Any volunteers to work on this? > > I will. How does it work? "DBD::Mock" comprises a set of classes used by DBI to implement a database driver. But instead of connecting to a datasource and manipulating data found there it tracks all the calls made to the database handle and any created statement handles. You can then inspect them to ensure what you wanted to happen actually happened. For instance, say you have a configuration file with your database connection information: This sounds like it could plug into the trace mechanism, either increasing its leverage, simplifying its implementation, or both. One could write session tapes during development, while talking to real database pieces, then reuse them to drive the Mock object. Another application would be to use a session tape as a log-filter, ie as a set of matching regexes which could subtract out lines of a dbi-log. Over time, developers could enhance the tape-derived filter-spec, and the dbi-log would get progressively smaller. At some point it would have only the anomalous stuff. They could then be used to validate/assert that chunks of activity were happening as expected, and perhaps kick DBI into trace(9) these log-subtractors would have to apply sequentially, and to nest,etc so they can match against sequences/loops that would be present in logs. And having just crept up to a line, let me cross it. Can new DBI2 have 2 logging levels under transactions ? Anything that commits (success) logs at 1 or 2, things that rollback are logged at 5 or 6. This should help unravel anomalous behavior by automatically putting your fovea on it. This also seems to relate (obliquely) to the way the new set_err() accumulates errors . now to go read those articles :-D
