DB Modeling and DB Management Example

[jaybuurdd]

Added a /models folder where the database schema can live. I did the layout for User just as an example of how to do it using mongoengine change as needed and each collection can have its own file in models folder like project.py, room.py, etc.

I also added an API endpoint to receive user data and save to db. Needed to modify the db config connection details a bit. The minimum we'd need for a local running db is db, host, and port.

Test on /users endpoint to create user via Postman

Result in MongoDB database via MongoDB Compass

[jaybuurdd]

Two things;

1. I'm not sure I understand what the repos/ folder is for and the subsequent classes. I'd think the functionality of the UsersRepo class can belong to the User model class.

2. How about we use specific versions of dependencies for stability?

1. repos folder is where our logic will be executed. views folder is where our routes and their endpoints will be. If you look create_user is executed when a put request is made to /user route. users.py in repos is executing the logic of taking the user data and saving it to a db. It's a variation of Model-View-Controller (MVC) pattern, to organize our app.

2. As for versions sounds like a good idea. I didn't make the file. I think @SHIV5T3R knows how to look up and add version to the pip lock file.

[believemanasseh]

Two things;

1. I'm not sure I understand what the repos/ folder is for and the subsequent classes. I'd think the functionality of the UsersRepo class can belong to the User model class.
2. How about we use specific versions of dependencies for stability?

1. repos folder is where our logic will be executed. views folder is where our routes and their endpoints will be. If you look create_user is executed when a put request is made to /user route. users.py in repos is executing the logic of taking the user data and saving it to a db. It's a variation of Model-View-Controller (MVC) pattern, to organize our app.
2. As for versions sounds like a good idea. I didn't make the file. I think @SHIV5T3R knows how to look up and add version to the pip lock file.

Alright, not bad.

[DatMomoAgain]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

[ZakariaTalhami]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

[jaybuurdd]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null.

So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

You are right. It would be updated and add the column. I don't know if the keys are something that needed to be generated right when the user is created but deleted_at could be updated at a later point in time when needed. The only reason those other fields can't be added to the post request is because we have create_user_parser to restrict them, when a user is making an account they aren't and shouldn't be sending us something like deleted_at date.

[DatMomoAgain]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

No i meant i was giving 'gh_access_key' a value during the post request and it was not reflecting in the db. None of the mentioned keys were being reflected even after giving them a value, they were not undefined

[jaybuurdd]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

No i meant i was giving 'gh_access_key' a value during the post request and it was not reflecting in the db. None of the mentioned keys were being reflected even after giving them a value, they were not undefined

I explained in the comment above that Mongo won't show those columns since those values are not passed and not allowed in the post request (create_user_parser is a validator). But, when we do need to add a value (e.g. deleted_at) it will populate the column when assigned and it'll appear in the database then. Right now it's currently None so the db won't show those columns until a value is set. It's apart of the schema so the db will accept it.

[DatMomoAgain]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

You are right. It would updated and add the column. I don't know if the keys are something that needed to be generated right when the user is created but deleted_at could be updated at a later point in time when needed. The only reason those other fields can't be added to the post request is because we have create_user_parser to restrict them, when a user is making an account they aren't and shouldn't be sending us something like deleted_at date.

It can be updated at a later point in time sure but i dont see why restrict people from adding those fields while using the 'addUser' api. Those fields are not being reflected in the DB even after giving them a value, they are not undefined.

The API request through postman

Data in MongoDB

The is_deleted field shows up even though its not in my request because its default value is set to false in the user model itself, there are no default values for other fields

class User(Document):
    username = StringField(required=True, unique=True, max_length=50)
    full_name = StringField(required=True, max_length=150)
    deleted_at = DateTimeField()
    is_deleted = BooleanField(default=False)
    email = StringField(required=True, unique=True, max_length=100)
    password = StringField(required=True, min_length=6, max_length=255)  # will store hashed password
    gh_access_key = StringField(max_length=255)
    gh_refresh_key = StringField(max_length=255)
    avatar = StringField()

    def set_password(self, password):
        """Hash the clear-text password and store its encrypted form."""
        self.password = generate_password_hash(password)

    def check_password(self, password):
        """Check if the provided password matches the hashed version."""
        return check_password_hash(self.password, password)

[jaybuurdd]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

You are right. It would updated and add the column. I don't know if the keys are something that needed to be generated right when the user is created but deleted_at could be updated at a later point in time when needed. The only reason those other fields can't be added to the post request is because we have create_user_parser to restrict them, when a user is making an account they aren't and shouldn't be sending us something like deleted_at date.

It can be updated at a later point in time sure but i dont see why restrict people from adding those fields while using the 'addUser' api. Those fields are not being reflected in the DB even after giving them a value, they are not undefined.

The API request through postman

Data in MongoDB

what's the purpose for gh_access_key and gh_refresh_key? When are they generated and what will they be used for?

[DatMomoAgain]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

No i meant i was giving 'gh_access_key' a value during the post request and it was not reflecting in the db. None of the mentioned keys were being reflected even after giving them a value, they were not undefined

I explained in the comment above that Mongo won't show those columns since those values are not passed and not allowed in the post request (create_user_parser is a validator). But, when we do need to add a value (e.g. deleted_at) it will populate the column when assigned and it'll appear in the database then. Right now it's currently None so the db won't show those columns until a value is set. It's apart of the schema so the db will accept it.

ahh ok, well just sent those images so others dont get confused, just wanted to be transparent about what i sent and what is showing up :)

[DatMomoAgain]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

You are right. It would updated and add the column. I don't know if the keys are something that needed to be generated right when the user is created but deleted_at could be updated at a later point in time when needed. The only reason those other fields can't be added to the post request is because we have create_user_parser to restrict them, when a user is making an account they aren't and shouldn't be sending us something like deleted_at date.

It can be updated at a later point in time sure but i dont see why restrict people from adding those fields while using the 'addUser' api. Those fields are not being reflected in the DB even after giving them a value, they are not undefined. The API request through postman Data in MongoDB

what's the purpose for gh_access_key and gh_refresh_key? When are they generated and what will they be used for?

i think its only purpose is authentication through github, I'm not sure how it really works, there was someone in discord who had a pretty good grasp of this

[jaybuurdd]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

You are right. It would updated and add the column. I don't know if the keys are something that needed to be generated right when the user is created but deleted_at could be updated at a later point in time when needed. The only reason those other fields can't be added to the post request is because we have create_user_parser to restrict them, when a user is making an account they aren't and shouldn't be sending us something like deleted_at date.

It can be updated at a later point in time sure but i dont see why restrict people from adding those fields while using the 'addUser' api. Those fields are not being reflected in the DB even after giving them a value, they are not undefined. The API request through postman Data in MongoDB

what's the purpose for gh_access_key and gh_refresh_key? When are they generated and what will they be used for?

i think its only purpose is authentication through github, I'm not sure how it really works, there was someone in discord who had a pretty good grasp of this

okay, I only asked because I don't know what their use case is yet so, I don't know if it'll be assigned during user creation. If it's for that it probably will. Don't forget the endpoint is just an example, modifications can be made as more things are made clear. I didn't plan on doing db management and schema.

[DatMomoAgain]

The fields 'deleted_at, gh_access_key, gh_refresh_key, avatar' dont seem to register in the database because 'create_user_parser' doesnt have those fields. Minor but mentioning it so we dont forget. Couldn't check the env variables properly because i dont have mongodb installed, so would be good if someone cross checks that

Please correct me if I am wrong. I think MongoDB doesn't add fields that have undefined or None values when creating. It doesnt mean that you cant add them later. On the other hand, MongoDB will add the fields if their values were Null. So I dont think this would be an issue. If an API was added to delete a user, updating the user's deleted_at should add the field without a problem.

You are right. It would updated and add the column. I don't know if the keys are something that needed to be generated right when the user is created but deleted_at could be updated at a later point in time when needed. The only reason those other fields can't be added to the post request is because we have create_user_parser to restrict them, when a user is making an account they aren't and shouldn't be sending us something like deleted_at date.

It can be updated at a later point in time sure but i dont see why restrict people from adding those fields while using the 'addUser' api. Those fields are not being reflected in the DB even after giving them a value, they are not undefined. The API request through postman Data in MongoDB

what's the purpose for gh_access_key and gh_refresh_key? When are they generated and what will they be used for?

i think its only purpose is authentication through github, I'm not sure how it really works, there was someone in discord who had a pretty good grasp of this

okay, I only asked because I don't know what their use case is yet so, I don't know if it'll be assigned during user creation. If it's for that it probably will. Don't forget the endpoint is just an example, modifications can be made as more things are made clear. I didn't plan on doing db management and schema.

Yeah i understand. Just pointed it out because i think people will follow your way of doing things, so just wanted everyone to keep in mind that create_user_parser might restrict the schema without them realizing. I think its clear enough now, so lets close the topic.