It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
It's a good idea to have an is_active flag on users. This way you can create them but not allow access until they've confirmed/paid up, and should it become necessary to disable their access later you can do it without nuking their entire account and dealing with whatever foreign key mayhem ensues.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
What are those reasons? I find is_* clear for boolean fields since it makes it easy to identify them as answering a yes-or-no question, and where naming things isn't about clarity it's really down to taste.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
The word is is redundant.
User.active = true
Why would you add it? You can tell that it is yes/no by the field/property type being Boolean. It's like putting 'equals' in your property name.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
It's not always obvious that something is a boolean unless you're looking at a table or class definition. Redundancy isn't universally evil: here it means you don't have to look up the type if you're just looking at usage.
I agree to having an is_active flag. Do you create users before confirmation in your apps? Do you have a flow that is like, "Hey, wanna join, enter your email" form collecting email -> create temp user with email, isactive=false, and token -> send email with button to confirm -> when user clicks on button -> go to website with token and get redirected to form collecting rest of stuff ?
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
My situation's a bit different since the stuff I work on is all enterprise software. We recently offloaded all our user management onto a single sign-on provider, but before that we did collect their information on signup and send them an activation/password reset email with a token (token hash and expiry stored in the database for verification). We didn't have a second stage, but then we weren't charging individual users.
It's a good idea to have an
is_activeflag on users. This way you can create them but not allow access until they've confirmed/paid up, and should it become necessary to disable their access later you can do it without nuking their entire account and dealing with whatever foreign key mayhem ensues.I would like to suggest that in stead of is_active, you call this property of user just active. (Boolean) this is more correct for many reasons.
What are those reasons? I find
is_*clear for boolean fields since it makes it easy to identify them as answering a yes-or-no question, and where naming things isn't about clarity it's really down to taste.The word is is redundant.
User.active = true
Why would you add it? You can tell that it is yes/no by the field/property type being Boolean. It's like putting 'equals' in your property name.
It's not always obvious that something is a boolean unless you're looking at a table or class definition. Redundancy isn't universally evil: here it means you don't have to look up the type if you're just looking at usage.
thanks for your thoughts. I'll have to look at the naming conventions.
Thanks for your comment, Dian!
I agree to having an
is_activeflag. Do you create users before confirmation in your apps? Do you have a flow that is like, "Hey, wanna join, enter your email"form collecting email-> create temp user with email, isactive=false, and token -> send email with button to confirm -> when user clicks on button -> go to website with token and get redirected toform collecting rest of stuff?My situation's a bit different since the stuff I work on is all enterprise software. We recently offloaded all our user management onto a single sign-on provider, but before that we did collect their information on signup and send them an activation/password reset email with a token (token hash and expiry stored in the database for verification). We didn't have a second stage, but then we weren't charging individual users.
Thanks for sharing your experience!
This also covers the case when the money are refunded (for any reason), or they brake the user policy of somekind (revoke access).