If items_total_$itemid isn't found, then your code would just ignore
anything in items_$itemid_$page and recreate it by doing a
memcache_replace(items_$itemid_$page).
Obviously, this only works in certain environments because when
items_total_$itemid isn't found you need to rebuild the entire result
set. Otherwise you end up with strange results on your later pages.
Anything over 100 records or so, you need to go about it pretty
different otherwise you will run into performance problems. But,
again depends a lot on your data and environment.
The other option is delete the key for each page when an update occurs
another advantage of having the total in a separate key.
On Sep 16, 2008, at 11:43 AM, dantro wrote:
thank you! it got clearer to me.
how do you remove the old items_$itemid_$page if you
only invalidate items_total_$itemid ? i thought of
never let the items expire. is that clever ? or should
memcache key always expire (even if time of expire lies
within months) ?
thank you again !
dan
On 16 Sep., 20:32, Joseph Engo <[EMAIL PROTECTED]> wrote:
Heres a little more detailed:
items_total_$itemid // Total number of items for this id
items_$itemid_$page // The items, separated by id and
page number (or
could be your LIMIT clause)
During request time, it first grabs the key that has the total number
of items for that item set, like the number of items in a category.
If that key is not found, it will pull everything directly from the
data source (SQL or whatever) ignoring what is stored in items_
$itemid_
$page
If that total key is found, it just returns the result set for that
page.
Now, lets say another section of the code modifies that result set.
You would do a memcache_delete(items_total_$itemid). This way, you
don't need to remove all of the other keys in the result set.
Make sense ?
On Sep 16, 2008, at 11:21 AM, dantro wrote:
wow! thank you for the really fast answer. I should have tried this
way before researching for
practical solutions! but back to your answer..
could you briefly give an example of your solution just in case to
get
it absolutely right as I
want to implement memcache now from scratch into a new version.
that would be very kind Joseph !
Thanks !
Dan
On 16 Sep., 20:10, Joseph Engo <[EMAIL PROTECTED]> wrote:
For my paginated result sets I have 2 types of keys. The total
number
of records and a key for each page of the result set. If any
changes
are made to that result set, I delete the total key. My code knows
if
the total key isn't found, it needs to grab a new result set.
That also makes it easy for me to update the result set from a
different location of the code base, since I only have to know
about 1
key and keep track of that.
There are many other methods, but this is what I personally use and
it
seems to do ok.
On Sep 16, 2008, at 10:59 AM, dantro wrote:
dear memcache fans
i am looking for a solution nearly a week. my problems deals with
memcache and pagination.
for example (without memcache):
my site offers the possibility to post comments. if an user
looks at
the comments site i query
the database via "SELECT [..] LIMIT x,y". per page I am showing 20
comments. If I have 100
comments it leads to 5 pages a 20 comments.
Now I am looking for a solution to put these comments into
memcache
parallel to mysql.
I don't know, understand how to deal with memcache if a comments
get
deleted or added.
I want to prevent querying the whole comments list ("SELECT id,...
WHERE forumid=$fid").
Do you have any solutions or what are your setups to handle
memcache
and mysql pagination
with "LIMIT x,y" when you add or delete entries.
Thank you very much for helping..
I really tried to find practical solutions!
Dan
---
http://jokeped.com - The greatest uncensored jokes!
