[FX.php List] Record Count after the fact- Revisted
Jonathan Schwartz
jonathan at eschwartz.com
Thu Feb 22 12:35:19 MST 2007
Thanks for the detailed explanation, Dan. I will be sure to unload
the session, once done.
Thanks again.
Jonathan
>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
>_______________________________________________
>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
More information about the FX.php_List
mailing list