500 Internal Server Error
- Thread starter Ⓐaron
- Start date
LicoriceAllsorts
Donator
I got one today, first time ever.
Cthulhu
Administrator
- AKA
- Yop
Random theory: extra lag from distance to the server makes you pass over some max request length threshold more often causing the thing to bork on a 500. Alternatively, your account has more Stuff in it (lulz) causing higher server load / longer query times until said query times out.
The Twilight Mexican
Ex-SeeD-ingly good
- AKA
- TresDias
Wednesday, folks. 
Cthulhu
Administrator
- AKA
- Yop
If programmed right (note: it probably isn't), the act of changing a username is done within the context of a transaction; unless said transaction is comitted at the end (which wouldn't happen if a server error interrupted the process), the changes won't actually be saved. Buuut again, that depends on whether vB was programmed properly, 
. Or maybe the PHP MySQL driver does that automagically, idk.
. Or maybe the PHP MySQL driver does that automagically, idk.
Cthulhu
Administrator
- AKA
- Yop
Yeah the DB supports it alright, but if the software just sets it to autocommit (which IIRC is the standard / was the standard in earlier versions of mysql (iirc it didn't even have transactional support at first), it won't do much good. I don't recall ever having to commit anything while working with mysql, come to think of it.
Fangu
Great Old One
? Won't do much good for what? Autocommit means the DB itself deals with the transactions, which is what we want?
Edit: Ah, geddit. Changing a username means changing several tables, not just one, and vB needs to have bundled those calls. Unless the DB has rules like - if the username is changed in the user table > udate all other instances. If trying to change username in one of the non-main tables > nuh-uh you can't do that, referring to main.
(That being said, I doubt vB is so olden it doesn't have separate functions such as 'update user' that bundles these operations towards the DB.)
Edit: Ah, geddit. Changing a username means changing several tables, not just one, and vB needs to have bundled those calls. Unless the DB has rules like - if the username is changed in the user table > udate all other instances. If trying to change username in one of the non-main tables > nuh-uh you can't do that, referring to main.
(That being said, I doubt vB is so olden it doesn't have separate functions such as 'update user' that bundles these operations towards the DB.)
Last edited:
Cthulhu
Administrator
- AKA
- Yop
Yeah, that's what I meant. Also yeah, I've been using vB for a number of years now, and I've never ran into an issue with data corruption like that. In fact, most operations on users are done via IDs (as they should), so even if a user rename breaks it's not that big of a deal. I think the extra operations done by vB when changing a username mostly involve rebuilding cached usernames - for example, every row in the posts table also contains the username of the user alongside the user ID. Not sure if this is for caching purposes, or for dealing with deleted users (no userID row matching the post in the user table -> revert to username stored in the post table).
Fangu
Great Old One
It's probably both. As in, caching purposes --> quicker loading. It takes time looking up the user table for every post - much more cost effective to sync the posts table when a user name is changed (as this doesn't happen nearly as often as accessing the posts table.) It's not very 3NF, but it's very efficient.
