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, let alone
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 kill
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
-++--+--+-
(0 rows)
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 output of
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 the
$dbh
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 $$dbhref
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
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 (@INC
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
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
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 wasn't
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.
And
. ;-)
- 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 started this whole thread. I
was happy just posting the hack and leaving
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
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
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
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't have to install SQLite2 if they don't want
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 installing manually via CPAN
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
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] -
From: Tyler MacDonald [EMAIL PROTECTED]
Subject: how
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 does
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 since
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 [mailto:[EMAIL PROTECTED]
Sent: Monday, January 02, 2006 3:28 PM
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
similar:
rationale:
I've
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
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--
sub
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:
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... a
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 commit at
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 the
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
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
handle
that keeps track of the transaction status.
Did you
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 drivers
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 or roll-
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
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You could try the 'mysqladmin -u user -ppassw -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
36 matches
Mail list logo
