[RESOLVED] Advice needed for sessions, please

Dolemite50

Hi,

I'm a session newb and looking for a quick fix before I take on sockets.

I'm trying to design a "You have a new PM" system. Currently if member23 leaves a pm for member55; the system updates the "has_new_pm" field in mysql where userid=55. Then on every page I use this:

if((!isset($_SESSION[has_new_pm])|| ($_SESSION[has_new_pm]==0){
SELECT has_new_pm from TABLE......
$_SESSION[has_new_pm] = mysql_result

I'm wondering if there is a way to avoid so many queries by somehow directly updating member55's $SESSION[has_new_pm] variable when the PM is submitted?
...or maybe setting a global array of members' new PM status like: $SESSION[userid][has_new_pm] ? I'm not even sure if a sitewide array is possible; please advise.

...or am I going about this the wrong way completely. I don't like the idea of so many queries, but I'm also uncertain about how much strain it would be on the server if it is possible to store the info globally. ANY advice is much appreciated!

Thanks

devinemke

i assume you have a separate table that stores the PM's? just add a BOOLEAN field that stores whether ot not the PM has been read by it's recipient. then when a user is logged in do a query to see if he/she has any unread PM's. something like...

$result = mysql_query('SELECT COUNT(*) FROM pms WHERE receiver_id = ' . $_SESSION['user_id'] . ' AND is_read IS NULL') or exit(mysql_error());
echo 'you have ' . mysql_result($result, 0) . ' unread messages';

Dolemite50

Thanks for the response. 🙂

I actually do have the mark_as_read field on the message table, but just querying the table once when they login doesn't help my cause. If a member is logged in for three hours; I wouldn't be able to notify them of any messages they've received during that time.

BTW, I'm still getting a lot of miles out of the advice you gave me for mysql optimizing many moons ago. Thanks!

devinemke

Dolemite50 wrote:
I actually do have the mark_as_read field on the message table, but just querying the table once when they login doesn't help my cause. If a member is logged in for three hours; I wouldn't be able to notify them of any messages they've received during that time.

what i meant was run the query on each page request. that way as your members move around the site they will always see if the have a new unread message.

Dolemite50

Thanks again.

Dagnab, I guess what you're saying is that there is no way to set Steve's $_session[has_new_msg] var when processing a message to Steve from Karen, or no way of storing that info in some sort of sitewide session variable available to Steve.

Querying on every page is essentialy what I'm doing now, and what I had hoped to eliminate or reduce. I avoid a few of them by not querying if session[has_msg] is already true or if session[can_recv_msgs] is false, but that still leaves 95% of my pageloads going "Yo mysql! It's me again, Steve! Do I have a message now? Do I have a message now? How about now?". Ideally would be to just rely on a session variable to inform of a new message and tell Steve to put a sock in it in the meantime.

I've been considering a $_session[pageload_counter] to have it only run the query every third pageload or something to knock down the query count a little more. What do you think? Am I just over-reacting here? Is a quick boolean query nothing to get all bent out of shape about? 😕

Weedpacket

The problem with not querying the PM database to see if there are new PMs is: how is the page supposed to know if there are new PMs without querying?

One vague possibility I see (that might have application in other areas) is: a table (it will only be small, so won't take long to search) into which messages can be put. So that if Steve gets a PM, a 'Steve: "You have a new PM!"' message is inserted into the table (don't worry if there's one already there: we'll deal with that in a moment) (you'd probably be better off using id numbers rather than actual strings). Then on each page, while you're checking the database to find out the user's details (like name and so forth), check this messages table as well for all messages addressed to that user. Once you've collected them, delete them from the table. To avoid multiple occurrences of the same message, select only distinct records.

You're still checking on every page load, but you've got the opportunity to check for more than one thing at a time; and "select message_type from messages where user='Steve'" on a small table would be a fair sight faster than "select count(*) from pms where user='Steve' and read=false" on a table that might get fairly bulky over time.

But, in the long run, whether this is overreacting or not would have to come down to experiment, methinks (he says, decorously covering his backside while somehow at the same time pleading "But I'm not a DBA!")

At least using a database means the messages can persist across sessions ("While you were out...")

(And I wouldn't select pms if I can possibly help it. But I guess it's part of the package........)

Dolemite50

Hehe!

Good to see you, Mr Packet.

I gave a condensed version of my setup so that it wouldn't interfere with me showing off what an idiot I am. Now that you're all thoroughly impressed I'll continue.

There are actually about 8 different message types that would trigger an alert. Each type has its own table in the db such as pms, inv, etc... (Don't kill me but they are actually named like that)
I also have a small table called new_msgs that contains user_id, 8 corresponding fields for the different notifier types, and a field called "has_new_msgs". When a member receives a message; the proper field in the new_msgs table gets a ++ and the "has_new_msgs" field is set to one. I did this so that I could quickly query a single field to see if the member has msgs or not, and if so; follow-up with the full-blown extraction. I know this adds an extra query when the member does have new msgs, but I figured that it was a good trade-off since 90% of the time they won't; and the script needn't have to constantly loop through functions to know that.

Iffins the member has new msgs I query the entire new_msgs table:
SELECT chat, inv, frm,...FROM new_msgs..
and then reference this array from my functions include:
$f_msg_array = array(chat => "Chat Invitation", inv => "FriendInvite", frm => "FriendMail",...");
to do:

while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
	   $i=0;
	   $arraynum=0;
	   foreach ($row as $col_value) {
	   	 if($col_value > 0){
		   $arraynum++;		
		   $field=mysql_field_name($result,$i);
		   $field_txt=$f_msg_array[$field];
		    $output_array[$arraynum] = "$col_value new $field_txt";
		}
	     $i++;
	    }		  

	}
	return $output_array;

...which gives the result as a few simple sentences to pass on to the Flash file in the header. Critique plenty welcome!

OK,..back to me sessions,..
"The problem with not querying the PM database to see if there are new PMs is: how is the page supposed to know if there are new PMs without querying?"
Here's where I'm lost. Isn't there a way for me to set site-wide variables in an array that are accesible to all visitors? For example; would it be possible to store CSS info in a global session array, and then when somebody clicked the green button it updated the $sitewide_array's "row_color" value to green, and members would see the change on the next refresh? Is the server actually capable of lugging around info like that or is it entirely on the user's end? If it is possible; couldn't I apply the same logic to update an array of userid's with new_msgs? I know that it wouldn't target a page that the member is on, but I could check to see if Steve's userid is in the global $users_with_new_msgs_array on pageloads. If it is; Steve's $_SESSION['has_new_msgs'] var gets set to one and his value removed from the array until the next message he receives. 😕

Sorry, I've been thinking about it too long. Thanks for jumping in WP. 🙂

madwormer2

Session variables are per user.

Isn't there a way for me to set site-wide variables in an array that are accesible to all visitors?
- Yes, it's called a database :p

Dolemite50

Fair enough, thanks everybody.