Jump to content

cammac

Members
  • Posts

    12
  • Joined

  • Last visited

    Never

Profile Information

  • Gender
    Not Telling

cammac's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. maybe this helps: wordwrap($string,150,"\n",true)
  2. yes, I have session_start() My theory is (though I haven't been able to duplicate it) that it is caused by a user having multiple browser windows open, then clicking the logout link and destroying his session in one window and then later clicking the logout link again in another window and as the session is already destroyed it gives the error. Or the session somehow times out and gets destroyed by the server automatically. E.g. per every 100 users logging out, 1 gives this error so I guess i need to check somehow if the session still exists or is destroyed.
  3. I'm getting from time to time these errors in my error log: Error 2 in logout.php, line 11: session_destroy(): Session object destruction failed logout.php: unset($_SESSION['status']); unset($_SESSION['uid']); $_SESSION = array(); // reset session array @session_destroy(); // destroy session. (LINE 11) I added the @ but it's still getting logged, is it possible to somehow check if the session is already destroyed or still exists before doing the destroy?
  4. I'm also thinking that with version 2 when I would select the comma delimited string and then go through the comma separated array as I would go through various rows in version 1, then e.g. if I would display 20 photos per album page, I would have to do only 1 mysql row selection instead of 20 rows in version 1, and just limit the comma separated list to 20 first items. So in theory 1 write instead of 99 writes, 1 read instead of 20 reads. Am I correct in my theory? Or is there a downside I'm not seeing.
  5. Any suggestions how to update the photo order when e.g. photo #99 would be dragged to position #1 - that would mean 99 rows would have to be updated in MySQL (instead of only 1 in Version 2)
  6. When users can drag and drop photos on a webpage to sort their order in photo album, which version to use for storing the photo orders: Version 1: Table "Album Categories" AlbumId, AlbumName, UserID (3 / Family Album / 32) Table "Photos" PhotoId, UserId, AlbumId, PhotoOrder 39 / 32 / 3 / 1 56 / 32 / 3 / 4 94 / 32 / 3 / 2 92 / 32 / 3 / 3 78 / 32 / 3 / 5 Version 2: Table "Album Categories" AlbumId, AlbumName, UserID, PhotoOrder (3 / Family Album / 32 / 39,94,92,56,78 ) Table "Photos" PhotoId, UserId, AlbumId 39 / 32 / 3 56 / 32 / 3 94 / 32 / 3 92 / 32 / 3 78 / 32 / 3
  7. yes, I have 2 fields userId, interests - with index on userId Assuming one would use the "all movies in one field" method, would there be any difference between using a comma separated list to using a space+quotes separated list in terms of performance when mysql searches through these lists for various users.
  8. When I designed it into one comma separated field my thinking was: When the user edits his favorite movies in a text area where they appear as comma separated in a textarea to the user... when he has 20 movies there and deletes 5 from the existing list and adds 2, then if we say a database has 20 million users and each has separate fields for all movies, lets say 100 million rows, then the script would have to go through 100 million rows to find all 20 of the user's movies and compare those all with the new list of movie titles submitted, then delete 5 rows and add 2 rows (7 write operations), whereas when all are in 1 field, it would be only 1 write (UPDATE) operation and mysql could stop searching as soon as it has found the 1st row with matching username, instead of having to find 20 more rows belonging to the user. Am I mistaken in my thinking that my method would be better for a very high traffic site?
  9. I have currently favorite movies stored in a comma separated list: (Terminator, Rocky, Die Hard) Then I noticed flick r which is a heavy traffic site is using space seprated lists with double quotes used for combining multi-word items: (Terminator Rocky "Die Hard") That made me start wondering which is the best method for storing in and searching from MySQL?
  10. hmm... I'm having a hard time understanding the reasoning behind MD5 encryption - if it's not possible to decrypt the pass again and send it to the user when they have forgotten it, then wouldn't it mean you would have to send the user a password-resetting link through e-mail, e.g: http://www.domain.com/resetpass.php?id=k8f8fjklh38 And then the hacker would just have to brute-force that, reset the pass and could even lock the user out. Also - maybe i'm wrong, but don't yahoo, msn, gmail, etc. all send the user their password instead of a reset link, so their passes are non-encrypted, or? And also wouldn't it be just as good to set a 10 minute login block after 3 failed login attempts to block brute forcing?
  11. here's an example of my union select with 2 users: (SELECT id, "updated profile", updated FROM profile WHERE id='18' OR id='19' ORDER BY updated DESC) UNION (SELECT id, "posted blog", post_time FROM blog WHERE uid='18' OR uid='19' ORDER BY post_time DESC LIMIT 0,1) UNION (SELECT id, "picture added", added_time FROM pictures WHERE uid='18' OR uid='19' ORDER BY added_time DESC LIMIT 0,1) ORDER BY updated DESC when I add "GROUP BY id" to the end or before last "ORDER BY" it gives error
  12. Hi, could any mysql gurus please help with figuring out if and how it's possible to do the following in a single mysql JOIN query: Select from multiple tables for multiple users the time of the latest update for each user - e.g. tables blog (can be multiple posts), photos (can be multiple photos), profile, interests, etc.: user1 - updated blog - 09-21-2005 12:23:53 user3 - added photo - 09-19-2005 11:34:34 user18 - updated profile - 09-18-2005 09:21:39 I tried the above with UNION SELECT but was unable to display only the latest update of each user as GROUP BY gave error.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.