A problem most siteengineers with a db should consider
Moderator: General Moderators
A problem most siteengineers with a db should consider
Hi
Let's say that a user of your site is in the middle of a several-pages-registration. On each page u store the values given by the user. Then suddenly, in the middle of the registration, the user exits your page. What about the now incomplete and useless values he's entered into your db?? How can these be removed?
Anyone got a solution to this problem. Is it possible to notify the server that the user is leaving and trigger a function of some sort that removes the values he entered?
regards tores
Let's say that a user of your site is in the middle of a several-pages-registration. On each page u store the values given by the user. Then suddenly, in the middle of the registration, the user exits your page. What about the now incomplete and useless values he's entered into your db?? How can these be removed?
Anyone got a solution to this problem. Is it possible to notify the server that the user is leaving and trigger a function of some sort that removes the values he entered?
regards tores
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Re: A problem most siteengineers with a db should consider
It would never occur to me to enter data into a DB until whatever process was finished. Entering data into a DB would eb the last thing that would happen in the process.tores wrote:Hi
Let's say that a user of your site is in the middle of a several-pages-registration. On each page u store the values given by the user. Then suddenly, in the middle of the registration, the user exits your page. What about the now incomplete and useless values he's entered into your db?? How can these be removed?
Anyone got a solution to this problem. Is it possible to notify the server that the user is leaving and trigger a function of some sort that removes the values he entered?
regards tores
Mark
- CoderGoblin
- DevNet Resident
- Posts: 1425
- Joined: Tue Mar 16, 2004 10:03 am
- Location: Aachen, Germany
On rare occasions (customer doesn't want it and will not accept anything to do with sessions, or legacy code where sessions are an absolute mess and shouldn't really be altered in any way shape or form) it is necessary to place data into a database when not complete. In this instance I would store the necessary data in a temporary area with a timestamp. Once the process is complete move the temporary values into the main db area. All temporary values lasting longer than 7 days or so get wiped via a cron job.
I agree sessions are the way to go but unfortunately what we all think is a good idea is sometimes not allowed
I agree sessions are the way to go but unfortunately what we all think is a good idea is sometimes not allowed
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
So true but aren't you just impementing a form of sessions though? Sure your gc is a cron job but isn't a session nothing more than an id, a timestamp and some data? But I agree workarounds are sometimes dictated by the customer and situation.CoderGoblin wrote:On rare occasions (customer doesn't want it and will not accept anything to do with sessions, or legacy code where sessions are an absolute mess and shouldn't really be altered in any way shape or form) it is necessary to place data into a database when not complete. In this instance I would store the necessary data in a temporary area with a timestamp. Once the process is complete move the temporary values into the main db area. All temporary values lasting longer than 7 days or so get wiped via a cron job.
I agree sessions are the way to go but unfortunately what we all think is a good idea is sometimes not allowed
- CoderGoblin
- DevNet Resident
- Posts: 1425
- Joined: Tue Mar 16, 2004 10:03 am
- Location: Aachen, Germany
The answer is yes, in reality you are but as far as any customer or "admin" person is concerned you don't use the word session. I have found with a lot of customers doing something similar to what is "dreaded", making sure you truthfully can say 'it does not use X' makes the customer happy whilst allowing maintainable and practical code.Buddha443556 wrote: So true but aren't you just impementing a form of sessions though? Sure your gc is a cron job but isn't a session nothing more than an id, a timestamp and some data? But I agree workarounds are sometimes dictated by the customer and situation.
In the short term (first customer contact) you have to develop trust. Later if you develop a good customer relationship and they trust you, you can start influencing their ways of looking at things. It is then you could start reintroducing the idea of "php sessions" pointing out how similar they are to what is currently going on and how it would be minor changes only to convert it and enhance things. The key is developing the trust.