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

Taming the beast that is the Django ORM – An introduction

davidhang.com

Post reply on HN
Print view View original

21–30 of 144 posts

Re: Taming the beast that is the Django ORM – An introduction

#21

Post by vandahm »

JodieBenitez wrote: post #17
cqqxo4zV46cp wrote: post #3

Django’s ORM is the first one that I ever spent a lot of time with. Throughout my career I’ve interacted with other ORMs from time to time. It wasn’t until I’d done that, that I realised, even though it’s not perfect, how fantastic the Django ORM is. I thought they’d all be that good, but no. I’ve read a lot of criticisms of ORMs, as I’m sure everyone else has. Some of them are certainly valid criticisms that are imm…

> I thought they’d all be that good, but no. I had the "pleasure" to use Doctrine once. Never again !

I used Doctrine for a few years, and I remember thinking that it was about 50% awesome and 50% terrible. I wonder what I would think if I came back to it today.

Re: Taming the beast that is the Django ORM – An introduction

#22

Post by djeiejejejej »

wsc981 wrote: post #8
Swizec wrote: post #6

Earlier quoted context omitted.

For me Django and ActiveRecord stand out as 2 good examples of what an ORM should be like. Both feel like they make the simple stuff super easy, the complex stuff figure outable, and the super hard stuff trivially possible with raw SQL and a decent mapping from that back to regular code. Although over the years my code trends more and more towards `.rawSql` or whatever equivalent exists. Even for the simple stuff. It…

I've started working on a .NET project that uses EntityFramework and due to some of the magic, I prefer just using raw SQL as well. I've used other ORM solutions in the past as well and I am not a fan ... But the team chose EF due to it supposedly being easier to integrate with whatever database the customer might be using and that seems like valid reasoning.

Yes I agree. That’s a valid argument, but there are other ways as well like SQLKata and other query builders.

Depending on the complexity of the product I think writing standard SQL92 will get you far as well.

I don’t get how an ORM will handle Postgres’ CTEs and windowing functions. Those are pretty basic and extremely useful features to me, but those require dropping to raw SQL. Each vendor has those useful particularities that you immediately lose by going ORM.

So in practice you are already required to make your queries as bland as possible where GROUP BY and JOIN is about as complex as it will get. I’d say just do SQL92 work around the limitations - which is something you’ll have to do anyway, but now more directly - and all major vendors will work OOB.

Re: Taming the beast that is the Django ORM – An introduction

#23

Post by vandahm »

WesleyJohnson wrote: post #10

Pretty decent introduction. Will there be additional parts that cover how to create GROUP BY queries in the ORM? I find even seasoned Django developers struggle with these. Also, I believe your code for creating an empty "data" migration is missing the "makemigration" command itself.

> Will there be additional parts that cover how to create GROUP BY queries in the ORM? I find even seasoned Django developers struggle with these.

The last time I needed to do that, I ended up crying "uncle" and writing manual SQL. I wasn't happy about doing it, but I was happy that the framework left me an escape hatch so that I could.

Re: Taming the beast that is the Django ORM – An introduction

#25

Post by murkt »

cqqxo4zV46cp wrote: post #3

Django’s ORM is the first one that I ever spent a lot of time with. Throughout my career I’ve interacted with other ORMs from time to time. It wasn’t until I’d done that, that I realised, even though it’s not perfect, how fantastic the Django ORM is. I thought they’d all be that good, but no. I’ve read a lot of criticisms of ORMs, as I’m sure everyone else has. Some of them are certainly valid criticisms that are imm…

In 15+ years I’ve only used two orms: Django ORM and SQLAlchemy. I’ve also skimmed docs for many others (some JS orms, etc), and those often look completely unusable.

SQLAlchemy is leagues above and beyond Django ORM. I can’t say I have nightmares from dealing with it, but it certainly was not pleasure. A bit too much magic here and there, not flexible enough and provokes too much bad practices. Re-defining save() methods to do a lot of work, anyone?

The best “orm” that I’ve ever used was not an ORM but a query builder — HoneySQL from Clojure. That one is fantastic. No ORM bullshit, no extra data loaded from DB, no accidental N+1 queries. Not reading docs on how to do a GROUP BY, everything’s just easy to write.

Frankly, we often use SQLAlchemy as just a query builder too. Makes life so much easier.

Re: Taming the beast that is the Django ORM – An introduction

#26

Post by bitexploder »

choilive wrote: post #7
cqqxo4zV46cp wrote: post #3

Django’s ORM is the first one that I ever spent a lot of time with. Throughout my career I’ve interacted with other ORMs from time to time. It wasn’t until I’d done that, that I realised, even though it’s not perfect, how fantastic the Django ORM is. I thought they’d all be that good, but no. I’ve read a lot of criticisms of ORMs, as I’m sure everyone else has. Some of them are certainly valid criticisms that are imm…

Django's ORM is acceptable - but I think Rails/ActiveRecord is superior albeit certainly more opinionated. Most likely just my personal bias speaking because Rails was the first web "framework" I cut my teeth on.

SQLAlchemy is the best stand alone ORM I have found.

Re: Taming the beast that is the Django ORM – An introduction

#27

Post by Too »

vandahm wrote: post #23
WesleyJohnson wrote: post #10

Pretty decent introduction. Will there be additional parts that cover how to create GROUP BY queries in the ORM? I find even seasoned Django developers struggle with these. Also, I believe your code for creating an empty "data" migration is missing the "makemigration" command itself.

> Will there be additional parts that cover how to create GROUP BY queries in the ORM? I find even seasoned Django developers struggle with these. The last time I needed to do that, I ended up crying "uncle" and writing manual SQL. I wasn't happy about doing it, but I was happy that the framework left me an escape hatch so that I could.

It's actually easy once you get it, it's just that they choose bizarre terminology that doesn't translate directly from sql. .values() and .annotate() ?!

Re: Taming the beast that is the Django ORM – An introduction

#28

Post by nprateem »

malux85 wrote: post #9
cqqxo4zV46cp wrote: post #3

Django’s ORM is the first one that I ever spent a lot of time with. Throughout my career I’ve interacted with other ORMs from time to time. It wasn’t until I’d done that, that I realised, even though it’s not perfect, how fantastic the Django ORM is. I thought they’d all be that good, but no. I’ve read a lot of criticisms of ORMs, as I’m sure everyone else has. Some of them are certainly valid criticisms that are imm…

I love the django ORM and then the REST framework on top of that. Define the object, hook it to a view, use our custom permission class, done. GET, POST, PATCH, DELETE all urls, filtering, pagination, search, ordering, complex multi-org multi-user object permissions handled automatically. Need custom logic? Just overwrite method. It’s a productivity superpower, sure there’s a lot to learn but that’s the price you pay…

Ninja is even better than the REST framework. Practically no boilerplate.

Re: Taming the beast that is the Django ORM – An introduction

#29

Post by nprateem »

For me the killer feature of django is the auto-generated admin UI. I initially started my last project using Spring boot, but I was astonished to find there was no equivalent.

I don't know how people build websites in any speed without such a tool. I guess they just waste time duplicating effort on an admin UI or pay for one of those tools that can generate one from an API (meaning they have to also build an API).

It's such a massive time-saver I switched to django after a week or so.

Re: Taming the beast that is the Django ORM – An introduction

#30

Post by KronisLV »

djeiejejejej wrote: post #19
Swizec wrote: post #6

Earlier quoted context omitted.

For me Django and ActiveRecord stand out as 2 good examples of what an ORM should be like. Both feel like they make the simple stuff super easy, the complex stuff figure outable, and the super hard stuff trivially possible with raw SQL and a decent mapping from that back to regular code. Although over the years my code trends more and more towards `.rawSql` or whatever equivalent exists. Even for the simple stuff. It…

Same here, but IMO it is related to skill and experience. Once you get sufficiently familiar with some paradigm the training wheels can come off. “Raw” SQL is already an abstraction. Over time all the implicit magic will get on your nerves. Trying to shoehorn two completely different worlds into one abstraction is not worth it: you get to learn today’s untransferable funky ORM syntax and idiosyncrasies while losing s…

> I concede however that handling of SQL, the field names, the relations, is annoying. But it’s core to the problem you are probably solving (some form of CRUD). Plumbing is annoying but as a plumber I’d say get used to it instead of wishing to be dancer.

It feels more like outsourcing said plumbing to someone that has done a lot of it in the past and will in most cases save you time, even if they won’t do everything the way you’d prefer yourself.

Throw in a bit of codegen and reading your current schema (if using schema first approach) and you’re in a pretty nice spot to be, except for the times when ORMs will get confused with non trivial joins and relationships, but typically then you have an escape hatch to have the query be in raw SQL while still mapping the outputs to whatever objects you need.

To be clear, I still think that mapping read only entities/DTOs against specialized database views for non-trivial data selection makes sense a lot of time regardless of the stack (or even some in-database processing with stored procedures), but basic ORM mappings are useful a lot of time too.

Post reply on HN