Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

death cob for cutie: Dec 30, 2006; dwarves won't delve no more
too much splatting down on Zot:4

ORM question: I'm reading https://docs.djangoproject.com/en/2.2/topics/db/queries/#querysets-are-lazy and it's making me ask some questions. Say I have code that looks kind of like this:

code:

sample_set = Model.objects.all()
filter_1 = sample_set.filter(x > 5)
filter_2 = sample_set.filter(y = "Blue")
filter_3 = sample_set.filter(z = True)

After the fourth line, zero actual database calls are made. But if I put filter_1, filter_2 and filter_3 into a context dictionary and render them on a page, that means three database queries are made, right? sample_set is never actually evaluated in any way, so that SELECT * FROM models query is never made, correct?

# ¿ Sep 29, 2020 19:56

Adbot: ADBOT LOVES YOU

# ¿ May 15, 2024 02:18

death cob for cutie: Dec 30, 2006; dwarves won't delve no more
too much splatting down on Zot:4

I'm helping to take over Votefinder, a Django project for keeping track of voting in games of Mafia on the forums. The previous maintainers of the project were not always Django/Python folks, and in doing an emergency scramble to re-establish the server while it was down I hit a big stumbling block because I didn't realize a previous maintainer of the project changed some assumptions about how Django projects are structured. I'm a bit leery of changing how things are organized in something using a big framework like Django, not necessarily for fear of weird behavior (you'd probably notice quickly enough) but for fear that it'll make the project harder to get into if things don't look and feel like a "normal" Django project does.

Another goon just put in a PR to get some better environment variable support via dotenv, and one of the things they did is move everything that was in settings.py to an __init__.py file in a folder called settings. I know that the way Python works this is more or less functionally equivalent and is not a huge change, but like I said before, I'm leery of anything that causes serious deviation from "normal" Django structure. Am I right in being a little gunshy about changes like this, or is this common enough in Django that even if it's not how django-admin startproject wants to arrange it that it shouldn't be too alarming?

# ¿ Mar 30, 2023 23:12

death cob for cutie: Dec 30, 2006; dwarves won't delve no more
too much splatting down on Zot:4

minato posted:

It also smells bad to me that __init__.py is being used for anything except making it easier for other modules to import whatever "public functions/classes/types" exist in the __init__.py's directory. __init__.py is the last place I expect to see code, and it always irks me whenever I find significant code and constants defined there.

I think this is a better way of expressing my feelings - all the settings for the DB type, logging, debug being on and off, etc. are in settings.py. Technically the contents of __init__.py are just declaring these based on reading them out from environment variables, so there's no logic per se - but then it feels like a change that's just made to make a change.

# ¿ Mar 31, 2023 00:31

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass