John Siracusa wrote:
Even without threads, wouldn't you rather have each apache child pulling
connections from a shared, server-wide pool rather than holding onto at
least one connection a piece whether they need it or not?
Sure. Can you figure out a way to do it?
Probably not in Perl 5 and apach
On 8/13/04 5:43 PM, Perrin Harkins wrote:
> This patch should make Apache::DBI work with subclassed DBI
> connections. The only downside is that it makes ALL of your cached
> connections subclassed if you give it one that is subclassed. Given how
> most people use DBI subclasses (for universal fu
On 8/13/04 10:34 PM, John Siracusa wrote:
> In the situation I described, for example, print will happily return 1 so long
> as what it's printing fits in the output buffer, regardless of whether or not
> the data is actually going to make it to the disk.
Er, that should read "regardless of whethe
On 8/13/04 5:22 PM, Perrin Harkins wrote:
> On Fri, 2004-08-13 at 17:05, John Siracusa wrote:
>> Even without threads, wouldn't you rather have each apache child pulling
>> connections from a shared, server-wide pool rather than holding onto at
>> least one connection a piece whether they need it o
On 8/13/04 5:23 PM, Perrin Harkins wrote:
> On Fri, 2004-08-13 at 17:15, John Siracusa wrote:
>> Something tells me you haven't been bitten by this bug yet, but let me save
>> you the grief. When, say, your disk fills up and you let that file handle
>> go out of scope, close() will silently fail w
Stas Bekman wrote:
Support for threads is only partial functionality of DBI::Pool.
Otherwise it should be a ground-up rewrite based on the experiences with
Apache::DBI and other wrappers so far. Apache::DBI should become just a
thin wrapper on top of DBI::Pool, to handle things like connect_on_i
Perrin Harkins wrote:
On Fri, 2004-08-13 at 16:37, Stas Bekman wrote:
IMHO, that should be folded into DBI::Pool
I'm not really interested in tackling pooling, since I don't plan to run
threads.
Support for threads is only partial functionality of DBI::Pool. Otherwise
it should be a ground-up r
This patch should make Apache::DBI work with subclassed DBI
connections. The only downside is that it makes ALL of your cached
connections subclassed if you give it one that is subclassed. Given how
most people use DBI subclasses (for universal functionality on all DBI
connections), this is proba
On Fri, 2004-08-13 at 17:15, John Siracusa wrote:
> Something tells me you haven't been bitten by this bug yet, but let me save
> you the grief. When, say, your disk fills up and you let that file handle
> go out of scope, close() will silently fail when trying to flush the buffers
> to disk.
If
On Fri, 2004-08-13 at 17:05, John Siracusa wrote:
> Even without threads, wouldn't you rather have each apache child pulling
> connections from a shared, server-wide pool rather than holding onto at
> least one connection a piece whether they need it or not?
Sure. Can you figure out a way to do i
On Fri, 13 Aug 2004 17:02:27 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > > Now that Perl has lexically scoped filehandles, there isn't any reason
> > > to explicitly call close() in most cases. ;)
> >
> > Tsk, for shame. Just wait until you forget to call close() after writing to
> > a fi
On Fri, 13 Aug 2004 16:45:59 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 16:37, Stas Bekman wrote:
> > IMHO, that should be folded into DBI::Pool
>
> I'm not really interested in tackling pooling, since I don't plan to run
> threads. All that I really want my module t
On Fri, 2004-08-13 at 16:43, John Siracusa wrote:
> It
> just seemed odd to me to be doing stuff in service of Apache::DBI, which was
> totally transparent until then.
That's one of the things I don't like about Apache::DBI. I don't want
it to be magical.
> > Now that Perl has lexically scoped f
On Fri, 13 Aug 2004 13:37:55 -0700, Stas Bekman wrote:
> Perrin Harkins wrote:
> > I would like to replace Apache::DBI with something oriented
> > towards connection management rather than porting old CGI scripts. I
> > don't like the disabling of disconnect. The old Apache::DBI could stick
> > a
On Fri, 2004-08-13 at 16:37, Stas Bekman wrote:
> IMHO, that should be folded into DBI::Pool
I'm not really interested in tackling pooling, since I don't plan to run
threads. All that I really want my module to do is extend the
DBI->connect_cached() method by adding the cleanup handler stuff from
On Fri, 13 Aug 2004 16:22:00 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
>> So what you're saying is that DBIx::* and Apache::DBI will simply never get
>> along because they both want to do the same thing, but use different (and
>> apparently incompatible) methods to do so?
>
> They both subc
Perrin Harkins wrote:
Er, yeah, "essentially" :) All the crazy re-blessing that goes on is
quite
a mess, IMO.
Agreed. I would like to replace Apache::DBI with something oriented
towards connection management rather than porting old CGI scripts. I
don't like the disabling of disconnect. The old
> Er, yeah, "essentially" :) All the crazy re-blessing that goes on is
quite
> a mess, IMO.
Agreed. I would like to replace Apache::DBI with something oriented
towards connection management rather than porting old CGI scripts. I
don't like the disabling of disconnect. The old Apache::DBI could
On Fri, 13 Aug 2004 12:50:44 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Also make sure that you read:
>
http://perl.apache.org/docs/1.0/guide/databases.html#Opening_Connections_With_Di
fferent_Parameters
Unfortunately, setting RootClass after the connect doesn't have the desired
effect (and
On Fri, 13 Aug 2004 12:51:32 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote:
> John Siracusa wrote:
> > On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
> >
> >>> return 200;
> >>
> >>this is wrong - you should be returning OK (0) not HTTP_OK (200) from
> >>handlers if everything is swell.
John Siracusa wrote:
On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
return 200;
this is wrong - you should be returning OK (0) not HTTP_OK (200) from
handlers if everything is swell. while 200 works in mp1 (due to mod_perl
"guessing" what you meant) you cannot do this in mod_perl 2.0.
Perrin Harkins wrote:
On Fri, 2004-08-13 at 15:25, John Siracusa wrote:
What does a DBIx::* module have to do in order to correctly call
Apache::DBI's no-op version of disconnect() when running under mod_perl with
Apache::DBI?
It needs to not set RootClass. Apache::DBI essentially subclasses DBI,
On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
> > return 200;
>
> this is wrong - you should be returning OK (0) not HTTP_OK (200) from
> handlers if everything is swell. while 200 works in mp1 (due to mod_perl
> "guessing" what you meant) you cannot do this in mod_perl 2.0. so, if
On Fri, 13 Aug 2004 15:32:03 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 15:25, John Siracusa wrote:
> > What does a DBIx::* module have to do in order to correctly call
> > Apache::DBI's no-op version of disconnect() when running under mod_perl with
> > Apache::DBI?
>
while perrin addressed your other issues, I thought I'd bring this up as a
learning point :)
>
> return 200;
this is wrong - you should be returning OK (0) not HTTP_OK (200) from
handlers if everything is swell. while 200 works in mp1 (due to mod_perl
"guessing" what you meant) you cannot do
On Fri, 2004-08-13 at 15:25, John Siracusa wrote:
> What does a DBIx::* module have to do in order to correctly call
> Apache::DBI's no-op version of disconnect() when running under mod_perl with
> Apache::DBI?
It needs to not set RootClass. Apache::DBI essentially subclasses DBI,
which is what R
What does a DBIx::* module have to do in order to correctly call
Apache::DBI's no-op version of disconnect() when running under mod_perl with
Apache::DBI?
Below is an example that illustrates a bug I found when using a particular
DBIx:: module.
---
package MyTest;
use strict;
use Apache::DBI;
us
Perrin Harkins wrote:
> On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote:
>
>>you can't do that with mod_perl 1.0 - you can $sub->run() but that result
>>goes right to the client.
>
>
> For comparison, how would you do this in mp2? With a filter?
pretty much. I believe that subrequests in
On Thu, 2004-08-12 at 14:05, Tim Howell wrote:
> Is there currently a way to do database connection pooling with
> mod_perl2?
No.
> I have tried using Apache::DBI with a use statement in my
> startup.pl but that doesn't seem to work.
It should. Make sure it comes before anything that uses DBI.
On Fri, 2004-08-13 at 07:14, Konstantin Yotov wrote:
> Everything is ok and scripts run perfect, but when I
> upload new script or modify existing one and run
> "apachectl restart" i recieve
> /home/httpd/bin/apachectl restart: httpd restarted,
> but the old script is loaded!!! Only if I do
> "apac
Looks like PHP has quite a lock on this market. Many
of the online collaborative systems are PHP/mysql based. Top open-source
contenders in this market would be:
Moodle (moodle.org)
ATutor (atutor.ca)
Ilias (www.ilias.uni-koeln.de/ios/index-e.html)
Note that these are collaborative learnin
On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote:
> you can't do that with mod_perl 1.0 - you can $sub->run() but that result
> goes right to the client.
For comparison, how would you do this in mp2? With a filter?
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: htt
MJW Lambrichs wrote:
> I want to publish the result of a dynamic request to a file. So within a
> handler I create a subrequest that gives me the result of the dynamic
> request.
>
> Something like: $sub = $r->lookup_uri("$page?id=$id");
>
> Now I want to get the results of this request and str
I want to publish the result of a dynamic request to a file. So within a handler I
create a subrequest that gives me the result of the dynamic request.
Something like:
$sub = $r->lookup_uri("$page?id=$id");
Now I want to get the results of this request and stream it into a file. Would using
Ap
Hello! :)
I've compile apache_1.3.31 with mod_perl-1.29 :
perl Makefile.PL DO_HTTPD=1 USE_APACI=1
APACHE_PREFIX=/home/httpd EVERYTHING=1
Everything is ok and scripts run perfect, but when I
upload new script or modify existing one and run
"apachectl restart" i recieve
/home/httpd/bin/apachectl res
I've seen conflicting information in docs, websites, lists archives,
etc. Is there currently a way to do database connection pooling with
mod_perl2? I have tried using Apache::DBI with a use statement in my
startup.pl but that doesn't seem to work. Using PerlModule Apache::DBI
in my httpd.conf d
36 matches
Mail list logo
