[FX.php List] Record Count after the fact- Revisted
DC
dan.cynosure at dbmscan.com
Thu Feb 22 11:12:33 MST 2007
Because HTTP is a so-called 'stateless' protocol, COOKIES were invented.
on the server SESSION variables exist so that the PHP scripter can
easily use COOKIES to store serverside 'state' variables that belong to
the browser - it makes HTTP somewhat 'stateful'. all of this happens
behind the scenes in PHP when you call session_start(). sessions are
cool because you used to have to program all of this by hand!:
on first page request from a browser, PHP sets a cookie in the browser
cache with session_start(). if the PHP script then goes on to set
SESSION vars, they are saved and stored by PHP using the equivalent of
compact() and serialize(). These stored files are linked up behind the
scenes by PHP to the cookie ID in a simple file-based database on the
hard disk.
on every subsequent page request if the site has already sucessfully
stored a cookie in the browser, the browser sends the cookie back to
PHP. PHP reads it and decides if it is expired. if not expired, PHP
loads all SESSION vars that have been set for that browser. PHP loads
the vars into RAM *from the disk* by doing the equivalent of
unserialize() and extract().
the SESSION vars are not 'sent' to the browser when they are loaded by
PHP for use in your scripts. they are simply loaded from the disk into
RAM by PHP at the server when you call session_start().
the warning about slow loading is that PHP will load SESSION vars into
RAM from the disk on every page that has session_start() on it. so, if
you have a huge amount of data in a SESSION variable it takes a huge
amount of time to load from the disk into RAM.
my advice is to use SESSIONs of course, but to be aware of the impact
they can have if you store too much and if you don't explicitly unset()
your SESSION vars once they are not being used anymore (ie. the user is
still using your website but not using the section where the SESSION var
is required).
an alternate way to avoid loading large SESSION vars on every page load
is to have the session_start() id be unique and load that one only
conditionally.
see http://www.php.net/manual/en/function.session-id.php
HTH,
dan
Jonathan Schwartz had written:
> Sorry for the delay in responding.
>
> A question regarding Dan's warning about putting data into SESSION Vars...
>
> My choice is to put the array data (from the secondary query request
> handled by PHP and not FMP) into either a regular variable ($temp_array)
> or a SESSION variable ($_SESSION['temp_array']), right? Is there a
> difference between the handling of these two types, as Dan suggested?
> Does the regular array stay on the web server but the SESSIOn array
> travel to the browser each time?
>
> Reviewing....For the initial search, it sounds like I will perform the
> first query to FileMaker, perform the second half of the query in PHP,
> store the results in the array, display results from the first page
> (records 1 - x) from the array. Request for records from subsequent
> pages will skip the FMP query and sub php query, and extract data
> directly from the array using skipsize to grab the right set of records.
>
> Back to the question on regular array versus SESSION array: Will the
> regular array be persistent from pages to page or am I forced to use a
> SESSION array to access the array data?
>
> Phew!
>
> J
>
>> I bet it's faster to load that data from SESSION vars compared to
>> rerunning the queries in FileMaker and do the AND / OR -ing of its results
>>
>> ggt667
>> On 2/21/07,* Steve Winter* <steve at bluecrocodile.co.nz
>> <mailto:steve at bluecrocodile.co.nz>> wrote:
>>
>> Yip... I did consider suggesting session variables, however with
>> the sort of
>> volume of data that I think Jonathan is talking about, I decided
>> like you
>> Dan, that this was going to be too much overhead to handle on each
>> page...
>>
>>
>> -----Original Message-----
>> From: fx.php_list-bounces at mail.iviking.org
>> <mailto:fx.php_list-bounces at mail.iviking.org>
>> [mailto:fx.php_list-bounces at mail.iviking.org
>> <mailto:fx.php_list-bounces at mail.iviking.org> ] On Behalf Of DC
>> Sent: Thursday, 22 February 2007 5:21 a.m.
>> To: FX.php Discussion List
>> Subject: Re: [FX.php List] Record Count after the fact- Revisted
>>
>> be careful putting too much data into SESSION vars as they are
>> loaded on
>> every page request. also, make sure you explicitly remove the data
>> when
>> you don't need it anymore so it doesn't load and slow the server.
>>
>> dan
>>
>> Gjermund Gusland Thorsen had written:
>> > And then you would only need $_SESSION['filteredResultMax'] and
>> > $_SESSION['filteredResultSkip'] to display your desired data.
>> >
>> > ggt667
>> >
>> > On 2/21/07, * Gjermund Gusland Thorsen* <ggt667 at gmail.com
>> <mailto:ggt667 at gmail.com>
>> > <mailto: ggt667 at gmail.com <mailto:ggt667 at gmail.com>>> wrote:
>> >
>> > I would put the new filtered result in
>> $_SESSION['filteredResults']
>> >
>> > ggt667
>> >
>> >
>> > On 2/20/07, *Joel Shapiro * < jsfmp at earthlink.net
>> <mailto:jsfmp at earthlink.net>
>> > <mailto:jsfmp at earthlink.net <mailto:jsfmp at earthlink.net>>>
>> wrote:
>> >
>> > Hiya Jonathan
>> >
>> > I had a thought from your last thread that I don't remember
>> > seeing --
>> > though maybe I just missed it...
>> >
>> > As the php goes through your FM results, can you put all
>> your
>> newly
>> > filtered, looped-through data into a new array and then
>> subsequently
>> > only use that? So that your $filteredResults array
>> would contain
>> > only the 300 'records' (of the 500 found by FM)? Then
>> it seems
>> you
>> > could do whatever you wanted to that data: display the
>> count, re-
>> > sort, prev/next, etc.
>> >
>> > maybe?
>> >
>> > -Joel
>> >
>> >
>> > On Feb 20, 2007, at 2:01 PM, Jonathan Schwartz wrote:
>> >
>> > > I'm baaa-aaack...with a wrinkle in the previously
>> discussed
>> issue
>> > > of post-processing a query result to accomplish a
>> combines
>> AND/OR
>> > > search.
>> > >
>> > > The problem now is dealing with PREV/NEXT links. I didn't
>> > realize I
>> > > had a problem until this point.
>> > >
>> > > The process:
>> > > 1) Perform part 1 of the search with FMP. Say it
>> returns 500
>> > > records. $searchResult[foundCount'] reports 500, but
>> this is
>>
>> > before
>> > > the secondary search and can not be reported back to
>> the user.
>> > >
>> > > 2) FMP passes 500 records back to PHP and Part 2 of
>> the search
>> > (for
>> > > loop) reduces the 500 records to say, 300. I can
>> report this
>> back
>> > > to the user, but only if I set groupsize high (500)
>> in order to
>> be
>> > > sure to count all the records resulting from the
>> second step.
>> Set
>> > > it lower and the count could be wrong.
>> > >
>> > > 3) I'm ready to post the first 20 records, but I have
>> 300. If
>> I
>> > > set groupsize to 20, I get say 15. Can't do that. If
>> I decide
>> to
>> > > accept the 300 records and stop the for loop at 20
>> records,
>> that
>> > > would be wasting alot of cycles just to to toss 90%
>> of the
>> data.
>> > > Plus, how do I now deal with the second 20 records
>> with PREV
>> and
>> > > NEXT links?
>> > >
>> > > Am I thinking about this correctly? I've already
>> asked the end
>> > > user if they *really* need checkboxes versus radio
>> buttons on
>> > this
>> > > search. ;-)
>> > >
>> > > J
>> > >
>> > >
>> > > --
>> > >
>> > > Jonathan Schwartz
>> > > FileMaker 8 Certified Developer
>> > > Associate Member, FileMaker Solutions Alliance
>> > > Schwartz & Company
>> > > jonathan at eschwartz.com
>> <mailto:jonathan at eschwartz.com> <mailto:jonathan at eschwartz.com
>> <mailto:jonathan at eschwartz.com>>
>> > > http://www.eschwartz.com
>> > > http://www.exit445.com
>> > > 415-381-1852
>> > >
>> > > _______________________________________________
>> > > FX.php_List mailing list
>> > > FX.php_List at mail.iviking.org
>> <mailto:FX.php_List at mail.iviking.org>
>> <mailto:FX.php_List at mail.iviking.org
>> <mailto:FX.php_List at mail.iviking.org>>
>> > > http://www.iviking.org/mailman/listinfo/fx.php_list
>> >
>> > _______________________________________________
>> > FX.php_List mailing list
>> > FX.php_List at mail.iviking.org
>> <mailto:FX.php_List at mail.iviking.org>
>> <mailto:FX.php_List at mail.iviking.org
>> <mailto:FX.php_List at mail.iviking.org>>
>> > http://www.iviking.org/mailman/listinfo/fx.php_list
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > FX.php_List mailing list
>> > FX.php_List at mail.iviking.org <mailto:FX.php_List at mail.iviking.org>
>> > http://www.iviking.org/mailman/listinfo/fx.php_list
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org <mailto:FX.php_List at mail.iviking.org>
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.441 / Virus Database: 268.18.1/690 - Release Date:
>> 16/02/2007
>> 2:25 p.m.
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition.
>> Version: 7.5.441 / Virus Database: 268.18.1/690 - Release Date:
>> 16/02/2007
>> 2:25 p.m.
>>
>>
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org <mailto:FX.php_List at mail.iviking.org>
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>>
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
>
> --
>
>
> Jonathan Schwartz
> FileMaker 8 Certified Developer
> Associate Member, FileMaker Solutions Alliance
> Schwartz & Company
> jonathan at eschwartz.com
> http://www.eschwartz.com
> http://www.exit445.com
> 415-381-1852
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
More information about the FX.php_List
mailing list