Henri Asseily <[EMAIL PROTECTED]> wrote:
> The problem is not to know when a request is done processing.
> The problem is killing requests that are processing for too long.
> If you want kill them safely, you may not be able to kill them until
> they're done, which defeats the purpose.
> If you k
Dean Arnold <[EMAIL PROTECTED]> wrote:
> >>Which brings me back to the notion of non-blocking requests. Assuming
> >>many/most client libs do support an async capability, and a OOB
> >>cancel, then it should be possible to standardize the behavior
> >>externally.
> >
> >Attempting to standardize,
Gene Zhang <[EMAIL PROTECTED]> wrote:
> instead of getting back an array or hash for each row of my SELECT, I
> want the results in one string, so that I can print it just like the
> psql shell client:
>
> e.g.
>
> "
> id | name | myid | tsid | comment
> -++--+--+
Michael Muratet US-Huntsville <[EMAIL PROTECTED]> wrote:
> Greetings
>
> I have had (& reported) this problem before and managed work arounds, but
> now I've got no choice but to get transactions working through DBI. The
> following simple script always fails:
Where is it failing / what is the ou
Kandi, Santosh <[EMAIL PROTECTED]> wrote:
> Hello,
>
>
>
> I thought that since DBI.pm and DBD (Oracle.pm) are basically Perl
> modules I could just copy the pm modules in my personal lib and set the
> PERL5LIB to point to them.
>
> Is my assumption wrong?
They are basically perl modu
JupiterHost.Net <[EMAIL PROTECTED]> wrote:
> >You know I AM a DBA and will withdraw the post as you guys seem to not
> >be able to grasp the concept.
>
> Ok kids ne nice :)
>
> The question is (assuming I understand it)
>
> Is there a way to get or have DBI set so it can be gotten the PID of th
Hetal Soni <[EMAIL PROTECTED]> wrote:
> Below is code lines to use library for Oracle or DB2:
>
> if ($opt_p eq "O") {
> $DBType = "Oracle";
> use DBD::Oracle;
> };
>
> if ($opt_p eq "D") {
> $DBType = "DB2";
> use DBD::DB2;
> };
>
> If I comment "use DBD::DB2;" line out and then compile it it
Mary Anderson <[EMAIL PROTECTED]> wrote:
> I have tried passing the handle in as a ref parameter, using $dbhRef = /*dbh
> (maybe this one was done incorrectly) and tried passing a $dbhRef as a
> value on a hidden textfield. None of these work. I tend to get
> "not an array" when I try to do $$d
DBIx::Migration::Directories 0.01 has reached CPAN:
http://search.cpan.org/~CRAKRJACK/DBIx-Migration-Directories-0.01/
DBIx::Migration::Directories provides you with a framework for managing
database schemas easily. You create a directory to hold your schema, then in
that directory create
Tim Bunce <[EMAIL PROTECTED]> wrote:
> > use Test::Harness; # tests use it so check it's loadable early
> > use Test::More 0.4; # tests use it so check it's loadable early
> I'd hardly call that a 'sinister problem'.
Excuse me for being a bit dramatic. ;-)
> I agree. (Though I be
Sridhar Madadi <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> When I am trying to build DBI module, I am getting the below error. I am
> running per 5.8.0 version
It looks like the perl in your path isn't 5.8.0, even if you have a
5.8.0 package installed:
> Can't locate Test/More.pm in @INC (
Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
> > I'm using the DBD::Pg driver and i've specifically turned "PrintWarn" off,
> > yet I am still getting spammed with messages like this:
> > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> This is a bug in DBD::Pg. I just committed a
Uwe C. Schroeder <[EMAIL PROTECTED]> wrote:
> Probably because the notice you see is a notice from the database engine,
> not from the driver.
OK, but in order for them to get to my tty, they have to bubble down
from postgres, through the UNIX/TCP socket I am talking to the driver with,
I'm using the DBD::Pg driver and i've specifically turned "PrintWarn" off,
yet I am still getting spammed with messages like this:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "aus_flag_pkey"
for table "aus_flag"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"a
rguing about it. I
like a good argument. ;-)
- Tyler
>
> >>> Tyler MacDonald [EMAIL PROTECTED]> 01-Feb-06 17:06 PM >>
>
> Yeah, I ditched Apache::DBI early in diagnosing this problem. Then I
> wrote that hack to solve it, which is what has sta
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > And here's some more conjecture: What if the ping just times out
> > because the server is really, really busy?
> DBI will replace it, removing all references to the one that failed to
> ping, and it will go out of scope and get DESTROY'ed.
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > Yes and no. If you can't ping the server, but the TCP socket is
> > still open, that means you essentially have this TCP connection to the
> > server that's not being used, in an open state, for the rest of the lifetime
> > of your apache server ins
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > I am opening a handle before apache forks. However, I was
> > able to verify that Apache::DBI wasn't loaded yet at that point (no
> > $INC{'Apache/DBI.pm'}), and I was issuing a disconnect() before the fork
> > took place.
> If Apache::DBI w
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> I've never seen Apache::DBI or connect_cached return a dead handle. I
> have had problems in the past with forking apps where I get back a
> handle that still pings but has been shared across processes so it no
> longer really works. Were you doing s
Apache::DBI and DBI's connect_cached both claim to keep your database
handles fresh and happy, but I've had numerous problems trying to get either
of them to work properly. If a database connection is dropped, sometimes I'd
have to refresh the page two or three times before the "internal server
err
Jeremy Nixon <[EMAIL PROTECTED]> wrote:
> It looks like it would work perfectly with connect_cached, which I hadn't
> known about, but now that I do, I'm all excited to change my code to use
> it instead of Apache::DBI.
*instead*, eh... I'm using it as well... Could this be part of the
pro
Apache::DBI claims that it will reconnect to a database if it's gone away.
DBD::Pg claims that it supports the ping method. However, when I restart my
database server while apache2 is running, all mod_perl pages that are
database driven return internal server errors, no matter how many times I
refr
pass.
As a start to solve/workaround this problem, I've sent the following
email to perl-qa@perl.org with the hope that there is a real solution in
place (or at least, somebody's had to deal with this before):
- Forwarded message from Tyler MacDonald <[EMAIL PROTECTED]> -
Ron Savage <[EMAIL PROTECTED]> wrote:
> > - If DBI_DSN is not set, default to depending on, and testing
> > against, SQLite.
> No. People should have to explicitly set DBI_DSN to make it do something.
> So, unset should be the same as set to empty string.
*whines* But this would break the
Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> > If you really want, make the SQLite tests optional if some environment
> > variable is set (eg, SKIP_SQLLITE_TEST).
>
> OK, I like the environment variable thing. That gives me the
> opportunity to warn a user instal
Ron Savage <[EMAIL PROTECTED]> wrote:
> On Tue, 10 Jan 2006 20:00:14 -0800, Tyler MacDonald wrote:
>
> Hi Tyler
>
> > OK, I like the environment variable thing. That gives me the
> > opportunity to warn a user installing manually via CPAN that they
> > don
Robert Loomans <[EMAIL PROTECTED]> wrote:
> > That's what it does right now. The tests don't depend on SQLite2
> > per-se, just a DSN that points to a DBI driver that supports transactions
> > (eg; pretty much everything except MySQL ;-)
> Errr MySQL supports transactions just fine at least
Ted Behling <[EMAIL PROTECTED]> wrote:
> Sorry for replying to my own e-mail, but I had another thought. What
> about just failing gracefully if SQLite2 isn't available? If it's
> installed, it gets used; if not, a warning is shown and the dependent
> tests are skipped.
That's what it do
DBIx::Transaction currently only depends on DBI, but for it's unit
tests to run you need a DBI driver available. If SQLite2 is available, it
gives you a nice default DSN to test DBIx::Transaction in a completely
self-contained environment.
The problem I'm facing is that smoke teste
" first reads better. Definately much better than
DBIx::DB. Thanks you two... when I release such a package in the (hopefully
not-too-distant) future, it'll be a Schema::RDBMS::. :-)
Cheers,
Tyler
>
> -Original Message-
> From: Tyler MacDonald [m
Jay Strauss <[EMAIL PROTECTED]> wrote:
> I you talking about cataloging pre-defined table layouts for specific modules
> or processes?
That, or modules that do all of their work on a database schema. Eg;
if you had a module that accepted longitudes and latitudes and built up a
waypoint da
ge from Perl Authors Upload Server <[EMAIL PROTECTED]>
-
modid: DBIx::DB
DSLIP: idhhp
description: DBI Database schemes with perl interfaces
userid: CRAKRJACK (Tyler MacDonald)
chapterid: 7 (Database_Interfaces)
communities:
dbi-users@perl.org
simila
Tim,
My DBI subclass places connect in it's root class
(DBIx::Transaction):
http://search.cpan.org/src/CRAKRJACK/DBIx-Transaction-0.002/lib/DBIx/Transaction.pm
Is this supposed to work as well, or should I move it into dr? (Is
there a situation/driver where this won't wor
Jaime Casanova <[EMAIL PROTECTED]> wrote:
> >Either way the end result is that some database drivers poison a
> > transaction if there's any error, others are selective about which errors
> > are fatal and which are not, and still others just don't care at all.
> that is a mis-conception...
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> The inconvenience I'll grant, but the non-standard claim I think
> needs some justification. When the database encounters an error in a
> transaction, it is supposed to report an error. An error in a
> transaction causes the whole transaction to fail:
Tim Bunce <[EMAIL PROTECTED]> wrote:
> > sub execute {
> > my $self = shift;
> > my $rv = eval { DBI::st::execute($self, @_); };
>
> I'd probably say:
>
> my $rv = eval { $self->SUPER::execute(@_) };
Yeah, maybe... I adopted that idiom because this doesn't work:
--snip--
John Armstrong <[EMAIL PROTECTED]> wrote:
> Hi - I'm soon to be doing a Perl app on the Internet, that'll need
> database. We want the db to be as "free" as possible, but still fully
> multi-user (web-based). Would the best route be MySql on Linux? Random
> access files? Something else? We want no
Tim Bunce <[EMAIL PROTECTED]> wrote:
> PostgreSQL is non-standard (and inconvenient) in this respect.
I chatted with Mischa (my work's resident DB guru) about this, and
according to him, the error behaviour when you attempt to SELECT from a
table that does not exist is "undetermined" in th
Tim Bunce <[EMAIL PROTECTED]> wrote:
> I'll guess that what you're really after is to be able to call begin_work
> again whilst an earlier begin_work is in effect and have the DBI keep a
> counter of how deeply nested the begin_work calls are. Then commit would
> decrement the counter and only comm
Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> > > Ok. If that's the only behaviour that can be depended on, then I
> > > guess the best choice would be to make a wrapper around the database
> > > h
Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> > Is there a way to ask DBI if it is already in a transaction?
> Read the AutCommit flag. :-)
It says,
Enable transactions (by turning "AutoCommit" off) until the next
call to "commit" or "rollback". After the next "commit
Paul DuBois <[EMAIL PROTECTED]> wrote:
> MySQL doesn't have sub-transactions (nested transactions). You can set
> savepoints within a transaction and roll back to a given savepoint and then
> continue the transaction from there.
Hopefully it will some day. :) I'm guessing other DBI driver
I'm looking through the DBI documentation and I can't find anything about
sub transactions (eg; if you do a "begin_work" ... "commit/rollback" when
begin_work has already been called).
This seems to work under DBD::Pg. Under DBD::mysql, I'm not sure if the
begin_work is just being ignored, or if c
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> You could try the 'mysqladmin -u -p -V'
> If your version of mysql is later than 3.23.6 it will support InnoDB.
Unless the "skip-innodb" option is enabled in their conf file. Also,
this requires that the user not only have DBD::mysql installe
Hello,
I'm working on a database package right now that will support
multiple backend drivers (currently just DBD::Pg and DBD::mysql, possibly
more in the future). With MySQL, you can only support transactions and
foreign keys if you have enabled the InnoDB database backend. This would
und
45 matches
Mail list logo
