Constraints on usernames?
-
We've already shown that it's impossible to change all references to an old username, so the old username has to stay.
What Chaos-damned system are you working on here?
-
I'll give you a hint: the first two letters are wt and the last four letters are orum.
-
You've already screwed yourself with NoSQL. There are ways to be able to fetch history, make sure that you always use the current username and are able to redirect from old names (though this requires never letting anyone else use any previously used name).]
And still use sane PKs.
-
If we put a field in the user data that says "this user was renamed/merged, look over here instead"
Then tie posts or whatever to both key on user and key on username, plus that would let you see when it was an admin doing impersonation.
-
Other people talk about primary keys in terms of the properties of the data.
Why? Just to piss off everybody who uses the terminology correctly? (I've never heard that usage before in my life, BTW.)
-
We've already shown that it's impossible to change all references to an old username, so the old username has to stay. If we put a field in the user data that says "this user was renamed/merged, look over here instead", that would make sense, and as a bonus you can actually determine what username a user had when they made a post.
Ok; but that's also a lot easier to do if the person is identified by a GUID.
Instead of "chaining" a lot of people together, you can just join the GUID with a list of all their previous names and the date range those names were active. One operation. Much quicker.
-
It's ICQ all over again.
Just go with ^\d{1,12}$
-
We've already shown that it's impossible to change all references to an old username
Lies. I see no regexes anywhere in this thread!
-
I'll give you a hint: the first two letters are wt and the last four letters are orum.
Oh. So the is deliberate
-
-
What specific NoSQL are you using? MongoDB can basically be used like a normal database if you just turn off eventual consistency. Joins are still a pain in the rear-end though.
-
I don't understand how "look up name in sorted table referenced by GUID in field" is easier than "name in field".
If a user had the name
yoloswaglord420
when they made a post, that post will forever be known as a post made byyoloswaglord420
.
-
Because the conversation went south faster than I can keep up:
Using user names as unique IDs(IE: case in-sensitive) has some positives.
- Helps to fight against obvious-troll accounts( Blakeyrat vs BlakeyRat)
- Some other helpful example?
Ignoring-login-names
- DisplayName and "UniqueIdentifierLoginName" need not be the same property. "IAmBob" could be my login ID but my posts show up as "Bill,TheEvilSatanicPersonWhoPostsOnthisForum". Still uniquely identified.
- Changing my DisplayName should just be a re-query of the database not some massive re-architecture of the application.
-
If a user had the name yoloswaglord420 when they made a post, that post will forever be known as a post made by yoloswaglord420.
So the name is a property of the POST and not of the USER?
Why?
-
I think it is safe to say that @Captain is from an alternate reality. His statements on various subjects pertaining to our industry show he uses different best practices and definitions than the majority of us. Also, his tendency to break out the Haskell and counterintuitive anecdotes further confirms my suspicions.
-
I can't fathom why you would use intelligent keys and lock yourself in that way when it's so easy to do it the right way.
-
I make a view like this:
map:
function(doc, meta) { if (/^user/.test(meta.id)) { emit(doc.email.toLowerCase(), null); } }
reduce:
null
and then I can query for accounts by email:
func UserIDsByEmail(email string) ([]string, error) { v, err := DB.View("wtforum", "user_by_email", map[string]interface{}{ "key": strings.ToLower(email), }) if err != nil { return nil, err } var ids []string for _, row := range v.Rows { ids = append(ids, row.ID[len("user"):]) } return ids, nil }
-
I don't understand how "look up name in sorted table referenced by GUID in field" is easier than "name in field".
It's easier to look it up in the post if you just store it in the post. This is what normal DB people would call denormalization, and in this case, it's probably a bad idea, because it will probably make other things more difficult for you down the road, assuming that your ultimate application isn't trivial.
-
So the name is a property of the POST and not of the USER?
Is this a "import posts from CS to Discourse" problem? Because this shit sure reminds me of... this here broken thing.
Or are you just making a new forum software that will be a Discourse clone, but in Go? Because I might be forced to buy a plane ticket and come over there to smack you senseless over the head.
-
Well, they can change their display name, but if they want to log in as the user that made the post, they have to type
yoloswaglord420
in the username box. That way, the URL of the post's author doesn't change on a whim.
-
Is this a "import posts from CS to Discourse" problem? Because this shit sure reminds me of... this here broken thing.
Except both of those are stored on RDBMSes.
-
i think the part where there is a display name could have been mentioned 50 posts ago and saved you 38 posts of WTF are you doings in this topic.
Or maybe you did mention it and no one read it because dicsourse.
-
Except both of those are stored on RDBMSes.
Aware of that. But it reminds me of DiscoJSON too much to ignore.
-
I kind of hinted at it when blakey said this:
A name isn't a person, a name is a property of a person. A person can have multiple names.
and I responded with this:
A username is a user. It doesn't make sense to have multiple accounts with the same username.
but I didn't say it outright because then this topic couldn't be featured in that one Lounge topic.
-
Is this a "import posts from CS to Discourse" problem?
Haha no, that'll never happen as I predicted months ago. Because I'm a goddamned SAVANT at recognizing dead-end software fuckwittery.
Well, they can change their display name, but if they want to log in as the user that made the post, they have to type yoloswaglord420 in the username box.
Right; I'm saying you should let people change the name of their accounts.
That way, the URL of the post's author doesn't change on a whim.
I think you're way too fixated on this. Here are two statements:
-
An Admin can rename a user
-
Users are renamed so often that their user page URLs become useless
Well, show that the disadvantage of 2) outweighs the advantage of 1). What you are doing now is premature optimization.
Plus it's an easy problem to solve: generate their user page URL from their GUID. That's what Steam does, and Twitter, and somehow people on Steam and Twitter change their user names all the fucking time and the world doesn't collapse down into dust.
-
-
-
that'll never happen
-
Because it's the original usage, as defined by E.F. Codd.
Also, there are good reasons to have a vocabulary for modeling data structures. Keys don't just appear in databases. They play the same role in things like dictionaries (i.e., the thing you look up to get a result).
Plus there are different types of keys. The concept of a natural key, for example, exists outside of any one database implementation.
-
What the fuck does this have to do with anything? I was commenting on
username
being a property of atopic
, and you link me to Go fucking up floats?
-
Plus it's an easy problem to solve: generate their user page URL from their GUID. That's what Steam does, and Twitter, and somehow people on Steam and Twitter change their user names all the fucking time and the world doesn't collapse down into dust.
You mean this Steam?
or this Twitter?
https://twitter.com/blakeyratIt's amazing that they both generated the same GUID for you!
-
Ok so here's what you got from those examples:
Blakeyrat is wrong! I am going to make a sarcastic reply to point out what Blakeyrat is wrong!
Here is what you should have gotten from those examples:
Hey look, two sites that are enormously successful have independently decided that it's not worth worrying about the case of breaking a vanity URL when a username changes. I should probably follow their example.
-
It's DiscoJSON.
-
Can you even change your username on Steam? Google? Microsoft's various user account systems?
-
Once again: . Your link complains about the library, not JSON itself. There is a reasonable representation of the data you're trying to store, broken libraries notwithstanding.
Also, I was talking about the guff Discourse spits out when you request a post: It has everything and the kitchen sink included in the post data, and user data is in no way separated from post data.
-
Let me spell this out for you: Go's
encoding/json
library uses a strange version of floating point numbers that encode into a different format than they were specified and then can't be turned back into the original form. It was meant as a silly reference to Go rather than an argument in any discourssion.
-
It was meant as a silly reference to Go rather than an argument in any discourssion.
That was extremely useful and relevant to my interests. I will now go to tend to the field where I grow my fucks. I'll let you know if I manage to grow any.
-
Can you even change your username on Steam?
Yes.
Google?
I don't know.
Microsoft's various user account systems?
Easily.
-
I don't know who theory is either.
Garmaring - b
-
Ah, but the real question...can you change your username on clintonemail.com (without hacking it like a Chinese spook)?
-
@ben_lubar said:
Can you even change your username on Steam?
Yes.
@ben_lubar said:
Microsoft's various user account systems?
Easily.
All of these results seem to be talking about the display name. Yes, I know I can change my display name. Can I change my username?
-
Can I change my username?
Yes, http://windows.microsoft.com/en-us/windows/outlook/add-alias-account
-
No; [a username is] a property of a user. It can be changed. You could potentially have multiples, as I said before. You could potentially have NONE, in the case where you let people interact with the system before creating an account.
This. Even if you don't want to support multiple names per user, it's still a good idea to assign each user a unique ID behind the scenes. If you're going to let users change their names, then you don't want to have to break all their old replies and quotes in the process... like Discosure does..
-
My point is that there's no reason
124893859
is a better identifier for a user thanusername_they_signed_up_with
. And if they want to migrate to a new account, there's always the ability to chain accounts. As an added bonus, you can mark sock puppets as "migrated to" the user that created them.
-
That doesn't delete the old username, which is exactly what my system does.
-
That doesn't delete the old username, which is exactly what my system does.
Well, technically, the MS system doesn't have a username; it uses the e-mail address in lieu
-
Sure, they make it optional:
If you want a new name for your account, you can add an alias, make the new alias primary, then remove the original alias.
But if you want to be draconian, go ahead. Honestly, you are only going to make things harder for your future self. Look at discourse as an example. They have so many WTFs that are directly tied to short sighted design decisions.
-
Hey, if a user wants to change their account's email address, they can go ahead and do that.
-
Can they login with an email address?
-
-
Hey, if a user wants to change their account's email address, they can go ahead and do that.
The MS email address is the user name. So while it isn't easy to change the user name in the MS system, it is possible.