[FX.php List] Record Count after the fact- Revisted
Steve Winter
steve at bluecrocodile.co.nz
Thu Feb 22 11:07:07 MST 2007
Hi Jonathan…
You’re quite correct, your two options are either store the results in a
standard array, or in the session array…
If you store them in a regular array ($currentSearch), then you will have to
conduct the FMP find/PHP subfind, every time the page is loaded, so even if
the user is going from one set of 20 to the next, you’ll need to pull in the
entire FMP set, run the PHP process, then output the correct items…
That’s the beauty of the $_SESSION approach, and why ggt said it would be
faster, since instead of having to do the FMP query, and the PHP sub-find
query, you can just pull the records that you need form the $_SESSION
variable... I would suggest that you follow this approach, and see what
performance is like…
The warning that Dan was making is that once you don’t need the session data
again, it’s good practice to clear it, as every page that has a
session_start() on it will then load that huge array, thereby slowing that
down… my suggestion for getting round that would be that you use something
like $_SESSION[‘currentSearch’] and then sub-arrays of that to store the
other data, so you end up with an array like;
$_SESSION[‘currentSearch’][‘foundCount’]
$_SESSION[‘currentSearch’][‘skip’]
$_SESSION[‘currentSearch’][‘searchParams’] //in which you store
what the user search for so you can display that
$_SESSION[‘currentSearch’][‘data’] // which actually has the
filtered results
That way you can simply unset($_SESSION[‘currentSearch’]) when you’re done
with it to prevent it being loaded in other places where you might use
session vars…
Let us know how you get on…
Cheers
Steve
_____
From: fx.php_list-bounces at mail.iviking.org
[mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Jonathan Schwartz
Sent: Friday, 23 February 2007 6:37 a.m.
To: FX.php Discussion List
Subject: Re: [FX.php List] Record Count after the fact- Revisted
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 <HYPERLINK
"mailto:steve at bluecrocodile.co.nz"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: HYPERLINK
"mailto:fx.php_list-bounces at mail.iviking.org"fx.php_list-bounces at mail.ivikin
g.org
[mailto:HYPERLINK
"mailto:fx.php_list-bounces at mail.iviking.org"fx.php_list-bounces at mail.ivikin
g.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* <HYPERLINK
"mailto:ggt667 at gmail.com"ggt667 at gmail.com
> <mailto: HYPERLINK "mailto:ggt667 at gmail.com"ggt667 at gmail.com>> wrote:
>
> I would put the new filtered result in $_SESSION['filteredResults']
>
> ggt667
>
>
> On 2/20/07, *Joel Shapiro * < HYPERLINK
"mailto:jsfmp at earthlink.net"jsfmp at earthlink.net
> <mailto:HYPERLINK "mailto:jsfmp at earthlink.net"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
> > HYPERLINK "mailto:jonathan at eschwartz.com"
jonathan at eschwartz.com <mailto:HYPERLINK
"mailto:jonathan at eschwartz.com"jonathan at eschwartz.com>
> > HYPERLINK "http://www.eschwartz.com"http://www.eschwartz.com
> > HYPERLINK "http://www.exit445.com" http://www.exit445.com
> > 415-381-1852
> >
> > _______________________________________________
> > FX.php_List mailing list
> > HYPERLINK
"mailto:FX.php_List at mail.iviking.org"FX.php_List at mail.iviking.org
<mailto:HYPERLINK
"mailto:FX.php_List at mail.iviking.org"FX.php_List at mail.iviking.org>
> > HYPERLINK "http://www.iviking.org/mailman/listinfo/fx.php_list"
http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> HYPERLINK
"mailto:FX.php_List at mail.iviking.org"FX.php_List at mail.iviking.org
<mailto:HYPERLINK
"mailto:FX.php_List at mail.iviking.org"FX.php_List at mail.iviking.org>
> HYPERLINK
"http://www.iviking.org/mailman/listinfo/fx.php_list"http://www.iviking.org/
mailman/listinfo/fx.php_list
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> FX.php_List mailing list
> HYPERLINK
"mailto:FX.php_List at mail.iviking.org"FX.php_List at mail.iviking.org
> HYPERLINK
"http://www.iviking.org/mailman/listinfo/fx.php_list"http://www.iviking.org/
mailman/listinfo/fx.php_list
_______________________________________________
FX.php_List mailing list
HYPERLINK "mailto:FX.php_List at mail.iviking.org"FX.php_List at mail.iviking.org
HYPERLINK
"http://www.iviking.org/mailman/listinfo/fx.php_list"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
HYPERLINK "mailto:FX.php_List at mail.iviking.org"FX.php_List at mail.iviking.org
HYPERLINK
"http://www.iviking.org/mailman/listinfo/fx.php_list"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
--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.iviking.org/pipermail/fx.php_list/attachments/20070223/e8094a1e/attachment-0001.html
More information about the FX.php_List
mailing list