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

Django 4.0

djangoproject.com

Post reply on HN
Print view View original

221–226 of 226 posts

Re: Django 4.0

#221

Post by ccanassa »

Majestic121 wrote: post #14

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the c…

Experience told me to be very conservative when picking frameworks. For small projects and personal, sure, just pick whatever you want and have fun! But for serious projects, you should stick with old and stable software.

I made the mistake of picking Flask for a really big project when these microframeworks were a fad and everyone was dismissing the big ones like Django and RoR. That was a very costly mistake. I learned the hard way provides way so many things out-of-box that I always took for granted but I had to manually implement in Flask.

Take tests for example, Django automatically makes sure that any DB operation is cleaned by the end of the test. That's sometimes that I never gave a thought until our Flask tests started leaking everywhere. The way that Django handles that problem is very clever and we had to manually do it Flask.

Re: Django 4.0

#223

Post by redact207 »

rlawson wrote: post #53
bencollier49 wrote: post #51

Earlier quoted context omitted.

May I ask what the projects were?

Car reservation system for auto dealers (never got traction) Covid screening application (sold) Inventory management (initial clients in alcohol beverage bottling/distribution)

May I ask how you discovered those two profitable niches? Did you already have contacts working there that just told you about it or did you go about hunting it down somehow?

Re: Django 4.0

#224

Post by firedrake93 »

tiangolo wrote: post #212
Majestic121 wrote: post #14

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the c…

Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new…

Yes, and one of the ways "documented here" is "Create a Pull Request"!

How is creating PRs going to get us "faster progress" when the very complaint from OP is that PRs are left to rot? And some PRs as simple as 1-line critical bugfixes that have been rotting for over 3 months? See, e.g., https://github.com/tiangolo/fastapi/issues/3665#issuecomment...

Shouldn't open PRs be prioritized over open issues anyway? Folks have put in the effort to not just complain about, but to FIX the bugs, and they are ignored.

Re: Django 4.0

#225

Post by gazpacho »

tiangolo wrote: post #212
Majestic121 wrote: post #14

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the c…

Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new…

Sorry but how do you want other people to close issues if they don't have the privilege to do so?

In the happy path a simple question was asked in an issue, a good concise answer can be given and the issue will be closed by the OP. That's already happening!

But often: 1. The issue is a bug -> (ideally) leads to a PR -> left to rot. 2. The question isn't well poised or is unclear. These should be redirected to StackOverflow or GH discussions, but it's kinda weird for a random person w/o affiliation to the project to do that. 3. OP stops responding at some point. Issue/PR will remain open. 4. It's a PR. We can't merge them for you, even if it's 1 line of documentation. You probably get tagged so much that tagging you won't help either.

All of these things can be solved in the same way: establish a governance model, bring on co-mantainers that can deal with the easier stuff, remain in charge of design decisions and larger changes.

Re: Django 4.0

#226

Post by robertlagrant »

handrous wrote: post #139
andybak wrote: post #43

Earlier quoted context omitted.

"Better" for whom? It was a long time ago that I surveyed the ORM landscape but I remember thinking at the time I was much happier using an active record style ORM. I guess I'm saying I'm always suspicious when I see "better" with no qualification. Everything has tradeoffs.

I, for one, find data mapper simply baffling. I look at it and can't even comprehend why someone might want to do things that way. Granted, I'm not fond of ORMs in general, but I at least understand the appeal of the active record pattern.

Presumably to mitigate the large downsides of Active Record.
Post reply on HN