Gonzalo Vattino

I want to clarify a couple of things. The database didn't take me 11 hours; I reached the limit where I had to devlog, and I wanted to do a devlog separating progress, but there was a limit. Well, I'm new to devlogging and the technologies I'm implementing, which is why my devlogs are so late and strange.

Creating the REST API in Python

The technologies used are: Fast-API, pydantic for the Fast-API schemas, and sqlalchemy for the database models (I learned that it's like translating the database into Python objects).

Database Configuration in the Project

In config/database.py, I create setup_mysql():

I verify that MySQL and MariaDB Server are working correctly.

I check if the specific raffles-manager user exists.

If it doesn't, I create it.

In config/__init_.py:

I import "createengine" and the setup_mysql() function.

I check if the user was created with the function I imported.

If it was created, I then create the engine that allows me to connect to MySQL with my user (still without a database).

In database/create.py:

I created a function that checks if the database exists (for greater scalability).

I created a function that creates the database (from a structure.sql in the same directory) and returns True when created successfully. It includes exception handling.

In database/connection.py:

Create an engine that now points to the database.

Implement a get_db() function for the endpoints.

In database/__init_.py:

Import "createdatabase()"

Check with the same function that was created

If it was created, import engine, SessionLocal, and Base.

In models/:

There is one .py file for each table in the database. Within each file, there is a class with the table name and its attributes.

Configuring routes in connection with the database

In schemas/:

There is a .py file for each table in the database. Within each file, there is a class for each endpoint with the name of the endpoint's functionality and the attributes it needs to take (I learned that these don't necessarily have to be stored in the database).

In routes/:

There is a .py file for each table in the database. Within each file, functions are defined. They have one or two decorators above them that specify the http method and the name of the route that executes it. Each file handles the display of the stored data (in bulk or for each record using the Primary Key and, in some cases, a pair of unique values).

Many functions are repeated; I am in the process of optimizing the code to make it more efficient.

In routes/__init_.py:

I created the `getrecord()` function to optimize the code. Includes exception handling and retrieves a record using the Primary Key.

In main.py:

I enable CORS (since without it, the endpoint tests wouldn't work).

I include the endpoint paths with a tag used for the automatic documentation generated by FastAPI in /docs.

Use of Artificial Intelligence

As I mentioned before, I didn't know how to create an API. I've been using Python for four years, but I'd never worked with FastAPI, SQLAlchemy, or Pydantic. I used chatgpt in the new Study and Learn mode, specifically asked it to meet the endpoint requirements (including JWS authentication, which I still need to do), and asked all my questions. I also used Github Copilot to resolve some bugs I didn't understand and to optimize the code a bit and make it cleaner, as I was using different practices in different files (different indentations and things like mixing camel case and snake case in different places).

ENDPOINTER TESTS
I tested many requests on different endpoints using different methods. I'm afraid I kept modifying the code, so I can't guarantee they'll still work the same. I'm still learning how to improve version management, devlogs, best practices, etc.

First of all, I have made the database with MySQL/MariaDB dialect.

It allows you to have several different raffle projects

(for example, you can have a Father's Day raffle and a different Mother's Day raffle).

In each project, you can have more than one set of raffles.

Each set contains the unit price of each raffle and its type, whether virtual or physical (paper) raffles.

Each raffle references its set, its buyer, and of course, its number, which is unique and non-nullable (thus used as the Primary Key).

It also contains the payment method and the status, which, upon making a payment, can be changed to sold or reserved if the payment is incomplete.

The payment date is also stored.

Buyers have a unique name and phone number pair.

This allows for people with the same name but not the same number.

In turn, if, for example, a son wants to use his mother's phone number after making a purchase, he can use it but in the son's name. The same number is called, but the winner is the son.

Just a basic webpage.