Re: Apache error logging under mod_perl
Yes the same applies to Apache-1.3: http://www.jsw4.net/info/list-archives/mod_perl/05-wk22/msg00045.html Tom Jonathan Field wrote: > Thanks Tom, good info I had not come across before! The page refers to > Apache 2, but they must have backported this to Apache 1.3 at some point > as well. > signature.asc Description: OpenPGP digital signature
Re: [mp2] $req->main->is_initial_req == 0 ???
On Monday 03 April 2006 23:18, Michael McLagan wrote: > "Main" to me says the one that was received by the server over the > internet -- from the client -- ie no matter how many requests deep > we are at any given point, main() always returns the top most item > on the pile. In that case, checking main->is_initial_request should > always be 1 and looking at the uri() should always be what the server > got from the client. Unfortunately, it is not that simple. is_initial_req() is implemented as !$r->main && !$r->prev If $r->prev is true then $r is the result of an internal redirect (created for example by $r->internal_redirect). If $r->main is true then $r is a subrequest (created for example by $r->lookup_uri or $r->lookup_file). For the initial request both conditions must be false. > If that's the correct interpretation of what the documentation says, > then I suspect there's a problem within the code as outlined in the > message subject -- main() isn't really main! > > I found this particular discrepancy with a structure similar to the > following: > > /file1.html: > > > > This creates a subrequest. > /file2.html > > > > and this another one, a subrequest of the subrequest. [...] > > > > > > > And what you see is exactly that request chain. Try your /file1.html as an ErrorDocument to see what happens when internal redirects pop up. Or try this CGI script. It generates an internal redirect as well: print "Status: 200\nLocation: /file1.html\n\n"; Torsten pgpJaMVIPsR9b.pgp Description: PGP signature
Re: Database transaction across multiple web requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Granted, I use a few MySQL features for this; I'm not sure if LIMIT exists in postgresql, and I'm fairly sure that the SQL_CALC_FOUND_ROWS directive (which will return the total rows in a select statement regardless of the LIMIT directives) doesn't... Postgres has LIMIT and OFFSET. To determine the number of rows returned, you can simply look at the return value of execute, or you can call $sth->rows: my $numrows = $sth->execute(1,2,42); my $numrows2 = $sth->rows; (b) Repeat the query (making sure there is a sort criterium) at each page request, starting at a variable offset and limiting the result set Generally, give solution (b) a try, by using LIMIT and OFFSET. It's a pretty standard way of doing things. As mentioned, this will not work so well if the table is changing between page views. If that is the case, and you truly want a static view of the table from when they ran the first request, you'll probably have to go to a lot more trouble, probably by creating copies of the table if updates or deletes are being run, or storing the primary keys if it is all inserts. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200603310921 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFELTsdvJuQZxSWSsgRAuvMAJwNIAoDo3vWGIEc6UI5Afme9HDsegCfRu7c q0Eif3BWRCetvt81tNurhIc= =z6Up -END PGP SIGNATURE-
Re: [OT] Database transaction across multiple web requests
Greg Sabino Mullane wrote: > >>> Granted, I use a few MySQL features for this; I'm not sure if LIMIT >>> exists in postgresql, and I'm fairly sure that the SQL_CALC_FOUND_ROWS >>> directive (which will return the total rows in a select statement >>> regardless of the LIMIT directives) doesn't... > > Postgres has LIMIT and OFFSET. To determine the number of rows returned, > you can simply look at the return value of execute, or you can call > $sth->rows: > > my $numrows = $sth->execute(1,2,42); > > my $numrows2 = $sth->rows; But will this return the total rows or just the rows that match the LIMIT ... OFFSET ... directive? In MySQL, at least, it will return the latter. The SQL_CALC_FOUND_ROWS directive is to calculate the former. Issac