Potential enhancements for book v2 (opinionated)

[badlydrawnrob]

BUG: @app.on_event("startup") is deprecated, use lifespan= handlers instead
Code currently works but will very likely stop working in future FastApi versions

@app.on_event("startup")
def on_startup():
    conn()

@Youngestdev This is explained in the advanced documentation for lifespan events, and I understand the general idea (in that documentation) but it uses contextlib and seems a bit advanced Python, so a rough rewrite of chaper 06 when calling conn() function would be very helpful.

I'm assuming conn() has to run once, and once only before startup (to create the database), and that get_session() opens and closes the database for read/write automatically (for regular use).

[Youngestdev]

Hi, @badlydrawnrob.

Yes, it is to run once before the application is started.

With respect to a rewrite, the team is looking into it. Lifespan events is a newer implementation.

[badlydrawnrob]

With respect to a rewrite, the team is looking into it. Lifespan events is a newer implementation.

I'm sure the rewrite is quite simple in this case, but a beginner probably can't figure it out easily for themselves.

[Youngestdev]

I'm not sure I understand 😅. When there's a new edition, Lifespan events will be explained in-depth.

[badlydrawnrob]

I meant that the actual code (as in, number of lines) to change this to use Lifespan events shouldn't be too difficult to implement, but explaining what Lifespan events are might not be trivial. I'm not sure I could do it unaided, without a fair bit of reading!

Would definitely be good to see an updated version of the book though. Does Packt offer lower cost upgrades?

[Youngestdev]

I don't have an answer to the Packt question, sadly. You can contact them directly instead.

Yes, I agree. All of these will be taken into account during the revision for the second edition.

[badlydrawnrob]

Cool. I'll check. I'll keep adding any major problems I see as it'll probably help you to revise things? If it isn't helpful, do let me know.

[Youngestdev]

I appreciate that! If you can, suggest your changes in this issue so we have a thread we can refer to.

[badlydrawnrob]

Current working code can be found here

@Youngestdev When I bought this book, it was specifically for SQLite and am a bit disappointed future chapters seem to be predominantly working with MongoDB (from looking at example files). I tried setting up MongoDB and the installation (on a Mac) was such an unpleasant experience I gave up (beginners I imagine will feel the same way).

I'll aim to create my own examples for the rest of the book with SQLite, but here are my thoughts half-way through the book:

Some questions and thoughts related to chapter 06 onwards:

1. Why the decision to use MongoDB and not SQLite?
   • I would've liked to see examples in SQL as mentioned
   • Postgres compatible may also be useful for others (SQLite seems to be generally compatible)
2. Is the await keyword necessary for SQLite?
   • By default SQLite is not async (so I expect the answer is no, unless using 3rd party tools)
   • The official async package is no longer supported, and I have a feeling that it's not entirely necessary to be async for 1-3k users.
   • Perhaps better to use a queue like RabbitMQ or SQLite sharding tool?
3. If commit() is used, does this close the connection once done?
   • Seems to be kind of a flushing method ...
   • A slightly more in depth writing of how this works would be helpful

My other criticism of SQLModel as an ORM

Some suggestions and guidance on using other ORMs would be helpful

• SQLModel seems to have a lot of growing pains (reading around on Reddit etc)
  • It might not be ready for production for some time.
• Some things that should be simple, like session.exec(select(Event)).count() are not possible ...
  • You have to use other workarounds

I've decided to give Peewee a try as it's lightweight and simpler than SQLAlchemy, which in my mind is a bonus. I'm mostly interested in prototyping apps, and simplicity and human readable is a big factor in deciding what technology to use. Peewee is also far better tested and stable than SQLModel.

from pydantic import BaseModel
from peewee import *

class Event(BaseModel)
  id: int
  title: str

class PeeweeModel(Model)
  id = IntegerField(unique=True)
  title = TextField()

data = {
  id: 1,
  title: "New event"
}

event = Event(**data)

def new_event(id, title):
  PeeweeModel(id=id,title=title)

db_event = new_event(event.id, event.title)

I'm guessing all I have to do is convert Pydantic types to Peewee ones and perhaps use JSONResponse instead of Pydantic return types, but would be great to get your input also!