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

Django and Postgres for the Busy Rails Developer

andyatkinson.com

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Django and Postgres for the Busy Rails Developer

#41

Post by wfleming »

infamia wrote: post #26
wfleming wrote: post #12

> Migrations in Django > > The Django approach has noteworthy differences and a slightly different workflow My explanation of Django's approach to migrations would involve a lot more expletives. It is by far my least favorite thing about the framework. - Fields are not-null by default, the opposite of SQL itself - Field declarations use argument names that sound like the SQL equivalents (default, on delete cascade/re…

> The default value thing combined with not-null by default It is interesting... I strongly feel the opposite after debugging far too many SQL queries where someone checked for an empty string but forgot to check for NULL. NULL by default is a SQL footgun IMO.

I prefer null as a clear “no value” marker to handle rather than special-casing handling of an empty string vs other strings, and if “empty string” isn’t considered valid that should be validation logic and that should never get stored in the database. But it’s certainly a matter of opinion and either can work as long as you’re consistent.

The point about Django’s choices about default and not-null though is that it can easily lead to crashes while you’re adding fields. If you add a string field with default=“” and don’t specify null=False, the generated schema will be a non-null field without a default value in SQL, but Django will backfill “” into all existing rows. To avoid downtime, you need to deploy migrations & apply them, then deploy the models.py/other code changes. But if anyone tries to write a new row before the new code finishes deploying after applying the migration, it will crash.

Re: Django and Postgres for the Busy Rails Developer

#42

Post by alephxyz »

wfleming wrote: post #12

> Migrations in Django > > The Django approach has noteworthy differences and a slightly different workflow My explanation of Django's approach to migrations would involve a lot more expletives. It is by far my least favorite thing about the framework. - Fields are not-null by default, the opposite of SQL itself - Field declarations use argument names that sound like the SQL equivalents (default, on delete cascade/re…

> Generally the field declaration/migrations system in Django feels to me designed to lead people down a garden path towards bad and dangerous behavior. If I had my druthers I'd enforce a policy in our Django app of "never run makemigrations, all migrations must be manually written SQL".

`makemigrations --dry-run` is helpful to see if your manual migrations are complete but besides that I agree

Re: Django and Postgres for the Busy Rails Developer

#43

Post by deaddodo »

aerhardt wrote: post #22
mostlysimilar wrote: post #16

Earlier quoted context omitted.

You can do that with Rails too. The difference is that Rails defaults are very good.

The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never he…

> I've never heard anyone but a Rails dev complain that it's "too verbose".

Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.

Re: Django and Postgres for the Busy Rails Developer

#44

Post by Lio »

Tronno wrote: post #19
karolist wrote: post #7

Earlier quoted context omitted.

Majority of learning surface will come from framework and not the language, if you need Python elsewhere just learn that as well, but this shouldn't move framework choice much.

Ruby, and Rails in particular, has a lackluster dev experience with any editor that isn't RubyMine. That's been a huge obstacle for me personally.

Each to their own I guess.

Personally I like the ruby-lsp and TPope’s Rails plugin in NeoVim.

I dislike heavy weight IDEs, I never find the juice is worth the squeeze.

Re: Django and Postgres for the Busy Rails Developer

#45

Post by kshahkshah »

deaddodo wrote: post #43
aerhardt wrote: post #22

Earlier quoted context omitted.

The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never he…

> I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.

That's curious to me honestly. I really prefer the ergonomics of Django's ORM compared to when I've had to use SQLAlchemy+Alembic in the past. I find alembic incredibly confusing and poorly documented. Not that documentation matters as much nowadays with AI

Re: Django and Postgres for the Busy Rails Developer

#46

Post by kshahkshah »

paulddraper wrote: post #36
pmontra wrote: post #4

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Mod…

Rails is so good it succeeded despite Ruby. Django's main benefits are 1. Admin interface 2. Python

Unfortunately for Rubyists (myself included) those are huge benefits though nowadays. It's much easier to find Python developers.

Having an out-of-the-box admin interface means business people can operationalize and workaround short comings of the software today, not tomorrow. I think functional admin interfaces can often be the difference between a successful company and one which is constantly operating off of spreadsheets in the background and never fully commits to their software.

Re: Django and Postgres for the Busy Rails Developer

#47

Post by dsego »

Supernaut wrote: post #3

As a longtime Rails developer who has experimented with Python but knew little about Django, I read this article with interest. Something that jumped out at me was the author's description of the "models.py file, which contains all the application models (multiple models in a single file)". I did some quick research and I gather that this approach isn't maintained as you move beyond the scale of a toy application. I…

You have dozens of apps (modules) each having its own models.py with a handful of models.

Re: Django and Postgres for the Busy Rails Developer

#49

Post by joshlemer »

brap wrote: post #48

With all of this praise Rails is getting, even still in 2024, it’s mind boggling how there was never a successful Rails alternative in one of today’s popular web programming languages. Nothing ever caught on.

Laravel and Django don't count?

Re: Django and Postgres for the Busy Rails Developer

#50

Post by theflyinghorse »

mrsilencedogood wrote: post #34
pmontra wrote: post #4

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Mod…

I've used rails for years, and have used old versions of django at one company, and used python extensively for non-web purposes. I think my take is that there's no middle-ground between Rails and some of the newer Java-based frameworks. Either I'm doing a side project or startup, and I need to go as FAST as possible, type systems and similar be damned, or I'm OK with not going as fast as possible and we're going to…

I was not aware of Javeline being used in the same way that RoR/django/Laravel would be used. Javeline provides primitives to build a backend/API layer only no?
Post reply on HN