🛢️🐍 #SQLModel - бібліотека для взаємодії з #SQL базами даних через #Python об'єкти. Розроблена командою #FastAPI для спрощення роботи з реляційними БД.
Ключові можливості:
• Інтуїтивний синтаксис на основі Python типів
• Повна сумісність з FastAPI та Pydantic
• Автоматична генерація SQL схем
⚡️ Технології: Python, SQLAlchemy, Pydantic
🛠 Платформа: Cross-platform
New blog post! I've been making great strides with my refactor, and now I'm on #SQLModel and #Svelte 5!
https://blog.blasphemess.com/build-one-to-throw-away/
It was so totally worth it to rewrite my game before launching it. Even if launching is the goal I'm rushing towards, I got enough feedback that necessitated a rewrite.
I need to learn more about how databases work and the best way to setup relationships in SQLModel. I was working on Rack Root tonight and am still running into an issue with some circular dependencies I'm having between various tables. I need these relationships to enhance the data/utility of the app, but might need to rethink how I'm actually putting them together.
The other fun part of this is that I'm learning that the way I test the app and the way I run the app isn't always the same. The tests will run fine the first time against my test Postgres container, but subsequent runs don't work because of how I tell the test DB to drop all data before running the tests. It's complaining about the relationships, but really I think I need to tell it to either cascade delete or just ignore something.
#homelab #rackroot #programming #webdev #fastapi #sqlmodel #databases #alwayslearning
fastmeshapi: a fast, persistent Meshtastic web app (intro)
I am probably holding them wrong!
This time I tried writing a web app not in #php but #fastapi + #sqlmodel (python) and #vue3 ( javascript). It kind of works well but refactoring is a nightmare.
In the beginning, it felt like I was having the best of both worlds -- Python and Vue3. Dev speed was good. Now maintaining and refactoring make me feel like I am having the worst of both worlds.
As a single dev, I should have stayed with #php!
New blog post is up!
How I handled tracking DHCP ranges in Rack Root, some things I ran into along the way, and how I improved my pytest output.
https://medium.com/@a.j.longchamps/rack-root-devlog-tracking-dhcp-ranges-c8272001fe3a
#pytest #homelab #rackroot #devlog #blogging #fastapi #backend #databases #sqlmodel #programming #blogging
Tonight's dev log update for Rack Root
I finally finished my refactor from sqlalchemy with sqlite over to SQLModel with PostgreSQL and refactored much of my code. I had a mixture of snake_cake and camelCase which has since been fixed to be all camelCase.
I adjusted many of my imports, classes, database tables, database foreign key relationships, and testing to fit the new design. I also had to adjust some of my tests because my IDs were off by one.
This database focused refactor also gave me all the structure and space I needed to build out the basic IPAM features. When a new network is added, all the associated IP records are created, and marked as 'Available'. If a gateway is set, that gets changed to 'Gateway' and when I implement DHCP ranges, that will be set to 'DHCP'.
I still have some things to do such as make sure the IP records cascade delete when a network is deleted, and fun stuff like that.
Now that the backend is (re)designed, I can get back to the front end side of things.
If you're curious to check out my code for this refactor, it's all up on my GitHub here:
https://github.com/alongchamps/rack-root/commit/0fc99dfcf10bf3ab6a5dfdc348894fe7e6221acd
#devlog #programming #rackroot #homelab #python #fastapi #sqlmodel #pytest #refactor #postgresql #backend
I learned something about using Python today, and this might influence how I write other parts of my code. I'm also open to ideas on the best way to go about this.
I'm now most of the way through a refactor where I'm switching to Postgres for my database and also using SQLModel over SQLAlchemy. I have all my classes written/rewritten and was running into an issue on the IPAM side of things when creating a new network. See if you can spot the bug as I write it out here.
Each API call in FastAPI will map to one function, with each class having their functions in their own file, for the sake of modularity/organization. I have a subnet.py file and ipRecords.py for those respective classes.
When a new subnet is created, I make the subnet in the database and then populate all of the IP addresses in the IpAddress table before returning to the FastAPI call. This means that one function call is chained to another one. Specifically subnet.createSubnet calls Iprecords.createIpRecord.
Both functions have a Session object coming in like this. Note that Depends comes from SQLModel and getDb() returns a database session, via yield.
myFunction( input1: int, input2, str, db: Session = Depends(getDb))
This means that when a new subnet is added, and then we call iprecords.createIpRecord, that doesn't get the proper result for getDb and we can't talk to the database.
My fix was to pass the db from one function to another so I can keep using it, and not pull it in via getDb on the inner function call.
Now that I'm through that mess, I can carry on with the rest of my refactor and get back to the main branch.
#pebkac #rackroot #programming #fastapi #python #ipam #homelab #opensource #sqlmodel
PA
Andrii Kuznietsov
True
Aaron Longchamps
Solve Computer Science
dilawar
Riverfount 
