#2 Wrong image displayed when another is uploaded
If someone is viewing the image display page
(photo.php), browsing through the images, and someone
else uploads an image, bad things happen.
Either:
If the person viewing the images hits refresh, the
previous image will be displayed.
OR
If the person viewing the images click on the next
image the same image will be displayed.
OR
If they click on any other image on the numbering
system at the top, the image before it will be displayed.
To resolve this problem:
The thing that triggers which image is displayed is the
'start' variable in the URL. When a new image is
submitted, the 'start' variable's value stays the same,
while any given image's 'start' value increases by one.
Now this doesn't resolve the problem at all, it just
tells why it happens.
A non-streamline resolution to this problem would be to
use the 'stimg' variable on all images. This will make
the correct image show up no matter how many were
uploaded while viewing them, but it uses loops
statements to determine the 'start' variable. In turn
it loads the server.
The best way to resolve this is to have a database of
all the images that are uploaded. And read the list off
of that, which removes the loop statements, but has the
same results.
--Good luck with this one--
Logged In: YES
user_id=1049886
How critical is this? Are users going to be complaining?
Logged In: YES
user_id=1049916
I think that if a server get's any type of significant
traffic, people will notice. If any thing, people will think
it is a server glitch. But it deserves higher priority than
3, I'll bump it up to 5, and hopefully with the development
of the flat image database, I can rewrite soem of the Photo
Display page, to make it not do this any more.
Logged In: YES
user_id=1049886
Is this still a problem?
Logged In: YES
user_id=1049916
Yes it is. I might end up rewriting the photo display page
to try to get rid of this problem...but that might not be
until 0.90 or something.
Logged In: YES
user_id=1070545
"The best way to resolve this is to have a database of all
the images that are uploaded" Don't we have that? Or is the
folder "imagedb" just a random entity that showed up somehow?
Logged In: YES
user_id=1049886
I doubt imagedb is a random entity, but I am curious why exactly this is
still happening.
Logged In: YES
user_id=1049916
Well after reprogramming all the stuff to image handle 4, I
found that certain ways of accessing the images are still
the old way: a list of image's filenames stored in an array.
But the way that the photo display page works is that each
image is assigned a number everytime it is accessed. So
there are no hard sets on the page. That is teh cause of the
error in the first place.
So the image handle 4 helped little to solve this problem.
But it may help some in the future when I try to solve this
problem.
What I will have to do, is as soon as the user access the
page for the first time, write a file under their name with
the current list of images, then show all the images in that
temperary database. I can add a script that detects if there
are any new images uploaded, then if there are add a button
that says "refresh" at the top, and it will get the new
list. Also, if the user get off the photo dispaly page, the
next time they go back to it, it will automatically get the
new list of images.
This will involve a complete rewiting of the page from scratch.
So it's my next big project (since it's part of our next
release).
Logged In: YES
user_id=1070545
I might be making an extremely stupid suggestion...but it
seems like if you know the starting photo...since photos are
sequentialy numbered you should just keep counting
up...obviously checking if the image exists first...why
would each image be given a temporary number??? that made
sense when the filenames were somewhat random, but now the
naming scheme should be making a database for you in a sense...
Logged In: YES
user_id=1070545
I'm not sure that solution is all that great either, because
the list of images can get rather big...writing 200 line
files just 'cause someone wants to view the photo page seems
a bit messy. I'm interested in the impact of that vs looping
through the db to find where the starting image is. Just
thinking a bit...if the starting image is the 7th in the
list say...and a new image gets added...the image can never
move below 7...so, we could perhaps add 7 as the beginning
point in the loop, and then go up until we find the
image...that should be pretty quick, as it is doubtful more
than one or two images will have been uploaded in the
intervening period...I guess an issue would be that now a
neew image will have appeared. I'm not sure having a
separate list should be there, because we wouldn't know when
the user disappeared...that solution means each user will
potentially have a pic database as more space that is taken
up. Ok, so back to my thought...say our image was number 7,
so start = 7. Now, we call the next page by going to 8, but
in the meantime someone uploaded a pic, which means 8 is now
the first image. But, we are gonna loop through and see that
the original image is now 8, so we do 8 - 7, which equals 1,
and add that to the curent value of start, which makes it
9. So, the user hits next, and goes to the next pic.
Oooo...what if someone deletets a pic...that could mess
things up a bunch. That messes up my quick loop
idea...Deletes should happen less though. Ok, thought, we
have a count of deleted images...that also gets in the GET,
we check that, and if it changes, then run the loop from
start - (change in delete). I think that's how I'm gonna do
things in mySQL, just cause...those are pretty quick querys
to run. Thoughts anyone? Did that make sense at all???
Logged In: YES
user_id=1049916
I think my assigned database solution may be the only
possble solution. But it may not be a totally practical one
when used on high demand servers. So I figure have a
preference that is default on to use the temperary personal
databases.
From reading our other soluterion (michael) I don't know if
it is a flawless solution either. If you write it for the
mySQL verion, I'll take a look at it and figure if it is
streamline enough (minimal loops) and possible for the flat
database system.