When | Mood | Music |
2013-04-25 14:54:00 | annoyed | I hope you die – Bloodhound gang |
So at the ‘show me your website – prove you did the work’ session yesterday, the lecturer added another requirement. This was the ability to delete a record from the database.
It was reasonably trivial to implement – I took longer than I’d have liked because I wanted safety trapping and reporting.
- only an admin could delete a user’s record/account (so delete function was only on the admin page)
- admin accounts can’t be deleted. (I’ve added a bit to the write up, suggesting a superuser who can delete admin accounts)
- The admin has to manually and correctly enter the deletee’s screenname and password. Mismatched or non-existent data earns the admin a lambasting.
- After a successful delete, the webpage reports User Arnöld, whose email was T-101@skynet.com, has been terminated.
I could have built in more safeguards or options such as You entered user JöhnCönnör but email address sarah.connor@resistance.com. JöhnCönnör‘s email address is john.connor@resistance.com, and sarah.connor@resistance.com‘s username is SärähCönnör. Did you wish to terminate
- JöhnCönnör/john.connor@resistance.com
- SärähCönnör/sarah.connor@resistance.com
- both
- neither
(The bullet points would be buttons.) However, this would have added to the complexity of the code without demonstrating any new skills, apart from possibly the PHP script which is called in cases of mismatch calling (and passing suitable parameters to) a separate PHP script to do the actual deletion. I’ve only passed parameters from PHP-enabled webpages to PHP scripts and JavaScript scripts, from PHP scripts back to PHP-enabled web pages and from JavaScript scripts to PHP scripts, not from one PHP script to another, so this might have been interesting.
But deletion is stupid! As was pointed out in the database systems course at the start of the MSc, and again in the Information Systems Engineering course last term, and by another correspondent, deleting a user-account is likely to delete transactions associated with that user. (Thank goodness I didn’t try to implement an e-commerce site – I’ve no idea [yet] how to set up relations in MySQL but I suspect it can’t be too hard.) Instead, such users should be marked as inactive. If the number of inactive users degrades performance, they can be moved to a separate database (with the option of reinstating them if so desired).
And as for adding an extra requirement 5 days before the submission deadline, BAH!
Anyway, I’ve now submitted my website code and printed my write-up (note no TurnItIn check!) to hand in on Monday.