Blog‎ > ‎

Peewee ORM FTS bug, uWSGI is a complete web server

posted Nov 30, 2014, 7:21 AM by Sami Lehtinen   [ updated Nov 30, 2014, 7:25 AM ]

Peewee ORM

I think I found FTS related bug?

Afaik, both codes should only delete record from FTS table where key matches the data.

# Code 1 - For some reason this seems to delete all records

fts_instance = FTS.get(FTS.key == key)
if fts_instance:
    fts_instance.delete_instance()

# Code 2 - This works as expected and deleted only matching key

FTS().delete().where(FTS.key == key).execute()

Any ideas why delete_instance deletes everything? Why?

uWSGI is a complete web server

uWSGI virtual hosts (multiple appliations) on same or separate hosts, etc.

So it seems that most of uWSGI guides are at least semi outdated and rest of guides instruct to use Nginx, even if it's not required anymore because uWSGI got it own efficient web request router. Now I'm just asking, what's the most efficient way to route queries to different apps and how to exactly do it. Most of guides I've seen, actually do run separate instances of uwsgi for each app and use separate ports or sockets. But with the internal router this shoudln't be required. Has anyone done it? I would prefer minimal setup where two scripts are loaded and served based on host (http request header) name. I know there are just so many ways to do it, but I would prefer doing it using plain uwsgi and it's parameters. Of course I can load app, which imports the other apps and then internally routes the requests between the apps based on the headers and so on. But this would be the cleanest solution afaik.

Latest uWSGI can also handle HTTP and HTTPS requests using pre-processing thread(s), as well as do content off-loading after request. So it can basically (at least in theory) handly request as efficiently as using separate http server with it like Nginx or Apache. Workers won't be reserved before data is ready for processing and workers won't be stuck with delivering the data after processing. As well as handle static files efficiently.

Some of the guides are based on really old versions which had to reserve a thread for whole processing time from connection to finishing connection.

Just like good old Apache pre-fork systems did. But times and things have changed since that. It seems that many people even still think that apache would work that way too.

Currently I'm looking for a simple solution to do vhosts using uWSGI only. Of course I can handle it on application level, but how to configure uWSGI to route requests based on host header, is still bit open.