![]() ![]() GET /users/ – dependent on a user being logged in and admin. If this dependency is fulfilled, user can update their own user data and these changes will be updated in the SQLite user database. PUT /users/me – dependent on a user being logged in. If this dependency is fulfilled, this request will return the user details in the response body. GET /users/me – dependent on a user being logged in. The following endpoints (other than create new user, which was mentioned in the previous section) are now available to use: read their own data information or that of another user (if admin).The v2 directory code now includes the ability for a user to: Once a change has been implemented, we also need to commit changes using the db.commit() function. The password entered will be hashed and a random otp_secret (which we used to generate the QR code in the previous post) is generated as part of the code. In the crud.py file you will see a new function, which enables the details for a new user to be added. The code has now been extended to enable new users to be added by posting to the /users endpoint. In the last tutorial, there was no way to create new users, aside from hardcoding them into the main.py script. Initially, you will see a database with no records. Once installed, you can click on Open Database and then select the. To interact with and view this data you can install the SQLite browser, which is freely available here. This is the file that contains the data in the SQLite database. db file is created, in this case it is called twofactor_app.db. To run the code, type uvicorn main:app -reload and open the docs page. In main.py we have the functions that determine the endpoints of the API, which can utilise the functions defined in crud.py. For this example, there is create, read and update but, at this point, no delete. Keeping these functions together in a separate file prevents code duplication and simplifies maintenance. CRUD stands for Create, Read, Update, Delete. The crud.py file contains the helper functions used to query the database. You can add others if you wish, for example “moderator”. There are currently two role types that can be used admin and user. The User schemas have been separated by read, write, read/write and update. Next, the schemas that were originally in main.py has now been moved into it’s own schemas.py file. In here we will declare the table name and columns that are in the user table along with their type and any default values. The models.py file describes the database structure, the tables and (if any) the relationships between the tables. The database.py is taken from the tutorial example in the FastAPI docs and I have kept it almost exactly the same aside from changing the SQLALCHEMY_DATABASE_URL. The code for this tutorial can all be found in the v2 directory in the github repo. To install SQLAlchemy you can run pip install SQLAlchemy from the command line. Using SQLAlchemy, we can manipulate the objects directly in Python which are then reflected in the SQL database. ![]() SQLAlchemy helps to achieve a consistent relationship between the object representation in Python and data storage in SQL. This is based on the FastAPI docs for SQL (Relational) Databases.Īs part of this application, we will be using the SQLAlchemy ORM (Object Relational Mapping) toolkit to interact with a backend SQL database.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |