Id for the UserAccount field? about brockallen.membershipreboot

[brockallen]

My only issue is allowing users to change their username -- think about forums where your username is your identity and if you were to change your username you can escape your prior identity. But perhaps that could be another global SecuritySetting.

[drewid]

Hmm, like the thought about the SecuritySetting.

Unfortunately I have been in too many situations where an key identifier was used that was not just "an identifier only the db knows about". Thus when the username type identifier was changed it caused all sorts of issues necessitating cascading updates and db craziness.

For just dealing with the two tables it wouldn't be needed, but the minute you starting referencing other tables...

[brockallen]

Sure, I totally understand about the benefit of using a semanticless PK. I think I was also having a problem with EF and cascading deletes (with the Claims table). Let me go double check on that.

[brockallen]

Ok, just went back and tested and as far as I'm concerned, I think it's fine to rework the PK for USerAccount to be an ID field. For the claims, we get a nice delete model if we leave all the properties as part of the key -- that acceptable?

[drewid]

Perfect with me - wish I would have seen this earlier to comment

[drewid]

any luck yet on a code change? I bow down to the expert ;)

[brockallen]

Ok, change made: eddb16a

I still have some more cleanup related to this -- migrations and the SecuritySettings.

[brockallen]

Ok, reworked migrations (started over since this was such a big change schema-wise and it was a pain to do a proper migration): cefd783

Also, added the new security setting to allow for usernames to be unique across all tenants: 5e1caed