Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some more things about Django I've been enjoying

jvns.ca

Post reply on HN
Print view View original

91–100 of 128 posts

Re: Some more things about Django I've been enjoying

#91

Post by selcuka »

3eb7988a1663 wrote: post #61
trojans1290 wrote: post #59

Earlier quoted context omitted.

So you’d prefer one file with all models? Do you break out into apps for business logic? Keep models in one app/file. Then domain driven design elsewhere?

As things get more complicated, I will separate out by some kind of concept. Which can be something as simple as: /coreapp /forms_foo.py /forms_bar.py /models_bar.py /models_foo.py /views_bar.py /views_foo.py You can do a more sophisticated module layout, but essentially something as straightforward as the above, all under a single "core" application. Prevents Django from fighting you when you want to work across the…

You can also have a /models/ package with foo.py, bar.py under it. It is easier to maintain.

As an additional bonus, you can add an __init__.py that imports all models if you want to be able to do a `from .models import FooModel`.

Re: Some more things about Django I've been enjoying

#92

Post by selcuka »

dnautics wrote: post #87

automatic migrations terrifies me. i use elixir/ecto. just write a migration! besides, some times you might want more than one schema for a db table (e.g. one with minimal information, for menus, dropdowns etc, and one with full information for your full CRUD operations)

> some times you might want more than one schema for a db table

Django has the concept of "proxy models" where you can define a trimmed down model for the same database table.

Re: Some more things about Django I've been enjoying

#94

Post by sgt »

leetrout wrote: post #40
ranedk wrote: post #9

I have been using Django since 0.95 and I haven't seen anything which is so flexible with amazing DSLs while also making it easy to understand the magic behind it. For the last 10 years, even in a Golang stack or Java stack, I still use Django for models and migration. I even have generators which generate Gorm (or other framework) DAO or Java hibernate classes using Django models. With LLMs, it becomes easier since…

> I still use Django for models and migration There are dozens of us! It's a great db management toolkit. I've used it to much success many times for things like managing migrations from mysql to postgres and php to python. My opinions: - Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries. I will die on this hill. No team is ever…

You may want to elaborate that Django apps are mini apps inside of the Django app (which is called "project"). Those unfamiliar to Django might think of a Django project as an app.

Re: Some more things about Django I've been enjoying

#95

Post by zzzeek »

pbalau wrote: post #32
echoangle wrote: post #28

Earlier quoted context omitted.

Not if you do the magic with getattr and comparison overrides. You actually need to do it on the metaclass because the Field as I wrote it isn't an instance but this works: from datetime import datetime class Filter(): def __init__(self, name): self.name = name def __gt__(self, value): return { "field": self.name, "operator": ">", "value": value } class FieldMeta(type): def __getattr__(cls, name): return Filter(name)…

If you change an operation that is meant to return a Boolean to return anything else, you are insta fired.

Hi, don't mind me, but

You don't need to return a boolean. You need to return an object that implements __bool__.

Get it ?

And even then, when you're dealing with objects that are special to expressions, you don't actually even need __bool__ that much

Re: Some more things about Django I've been enjoying

#97

Post by physicsguy »

CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

I think people in the Python world just don't yet have a good mental model of async either. I recently have had conversations with a number of people who have switched to FastAPI because "it's faster" even when they're using it to serve ML models which are compute bound and there's nothing you can await on.

Re: Some more things about Django I've been enjoying

#98

Post by BrenBarn »

woadwarrior01 wrote: post #31
7bit wrote: post #21

Earlier quoted context omitted.

There may be many reason other than rejecting that suggestion leading to what it is know. Your statement somehow suggests that it was deliberately decided against what you propose. I don't think we know that. I can't quite picture how operator overloading would look like, could you give an example?

You might want to look at Peewee's query filtering syntax. https://docs.peewee-orm.com/en/latest/peewee/querying.html#f...

I have, yeah. That's kind of my point: other ORMs do this better than Django.

Re: Some more things about Django I've been enjoying

#99

Post by a_c »

My experience from running a django app with thousands of migrations and dozen of apps

- Testing involving models is slow. It runs all your migration. Python's own "Unittest" is fast for functions not involving models.

- The suggested pattern for business logic is "active record", which is putting functions about a model alongside the model itself. Good for clean case. Doesn't really work when your operation involve multiple models.

- But if you put function about a model inside a model, the migration doesn't serialize the function into migration history (I could be wrong)

- "Data" migration is handy when you want enum-like data in database available to all teammates. e.g. list of currencies

- It is very tempting for new team member just to create an django app, with its own view and model, because it feels like starting a fresh without needing to care about existing business context. On the other hand, designing conceptual boundary between apps is very important. Because starting app is easy, and often (not always) wrong.

- The squash migration utils are limited because I guess of relatively low usage. It squashes linear migration history (with manual curation of starting and ending migration node I think? Not sure about latest state). I wrote a util to squash whole migration history by finding linear segments and squash those segment of history one by one. Didn't release it, but wrote some notes https://gist.github.com/kmcheung12/08b4c234b38c23efd43550da9...

Re: Some more things about Django I've been enjoying

#100

Post by ptx »

hecreto wrote: post #57

Not to be a downer since a lot of JEvans’ content is great. People should really give .NET a try. I don’t know if we are just old greybeard curmudgeons who look at this and go “is this a new thing? haven’t we been doing this for decades?”, but .NET out of the box with a few packages for databases, logging, etc is so pleasant you don’t even think about it. Maybe it’s just not a vocal community idk.

.NET also comes with "telemetry" built-in that sends your data to Microsoft without asking for your consent: https://github.com/dotnet/sdk/issues/6145

I wouldn't want to run software from someone who thinks taking such liberties with my machine and my data is OK.

> so pleasant you don’t even think about it

I'm sure Microsoft would prefer that people don't think about Microsoft is doing to them. But when do you think about it, you might reconsider using Microsoft software.

Post reply on HN