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

51–60 of 144 posts

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

#51

Post by andybak »

bruce343434 wrote: post #48
santiagobasulto wrote: post #41

I think Django's ORM is just AMAZING. And as with every other tool, it has to be used wisely. First, it let's you get started quickly and prototype. You can write unit tests, make sure everything is working as expected, then count queries and make sure you're being efficient with your SQL engine. Second, and even more importantly, it's crucial in the definition of the app and the Schema. Thinking in high level "class…

We've had serious trouble with migration merges when two people work on different parts of the code, yet in the same module, and they both generate a "migration nr. 6" on their feature branches.

Not at my desk but from memory, this is a something with a clearly documented "solution".

I put that word in quotes because I don't want to imply it's a problem - it's just something you need to know how to handle.

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

#52

Post by thestepafter »

AmericanChopper wrote: post #47
rowanseymour wrote: post #39

Earlier quoted context omitted.

The Django ORM makes migrating database state (a hard problem) super easy. It also makes GROUP BY queries (a relatively easy problem) oddly difficult. Use an ORM where it helps, use SQL where it doesn't.

I personally don’t think DB migrations are that difficult, and I’d say they can be done a lot safer without an ORM. I’ve also never found an ORM that was easier to learn and overall easier to use than SQL. I’ve never understood how ORMs became so popular, I don’t get how somebody can look at how opaque and complicated they are and conclude that learning an ORM is easier than just learning SQL.

100%. ORMs are good for basic queries but the messes I have seen written joining 20 plus tables with conditions and left joins, etc, oof. Just use SQL, it’s much cleaner and easier to maintain.

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

#53

Post by andybak »

santiagobasulto wrote: post #42
santiagobasulto wrote: post #41

I think Django's ORM is just AMAZING. And as with every other tool, it has to be used wisely. First, it let's you get started quickly and prototype. You can write unit tests, make sure everything is working as expected, then count queries and make sure you're being efficient with your SQL engine. Second, and even more importantly, it's crucial in the definition of the app and the Schema. Thinking in high level "class…

One common pitfall with Django ORM's is that it makes it very easy the use of inheritance in models. But as we know, the "impedance mismatch" between OOP and the Relational model is a problem. It has happened that a dev in our team was populating an endpoint that used inheritance and when looking at the number of queries we were over 100. But the solution in those cases is just OUTER JOINs and CASE. Especially since…

You have to use the ORM with a bit of awareness of the query it it generates. Django provides plenty of tools and great documentation for reducing, combining and managing queries. It's not like it's a deep dark corner.

It's like understanding memory allocation if you're writing c. It's just part of the job

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

#55

Post by yurishimo »

rowanseymour wrote: post #34
wruza wrote: post #32

Earlier quoted context omitted.

What would be the best way?

If it were up to me there'd be a way to completely disable it globally for all models. Let me explicitly enable it when I'm just shelling around or checking results in unit tests. It is not a feature for production environments.

Laravel does this (or at least has a config for it). You can disable lazy loading in non-production environments which will throw fatal errors whenever a model is lazy loaded.

The nice part is, in prod, that code _allows_ lazy loading since application stability is more important. Hopefully at that point you have a good performance monitoring tool that will alert you to that problem. Laravel also has hooks to more granularly fire events about lazy loading if you want to roll your own notification solution.

So I disagree with your assertion. Lazy loading is ONLY for production. While it is possible that such a feature could potentially bring down your DB server and therefor your app in general, if the feature is turned off locally, then hopefully you’re catching it well ahead of time. And if you’re running small app with no users, meh. For large apps, hopefully your team’s standards are enough to keep the monsters at bay.

Lazy loading is a sharp knife that requires skill to use appropriately.

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

#56

Post by neonsunset »

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.

It's pretty straightforward, and LINQ method names map quite closely to SQL.

If you are not a fan of it however, you can use queries directly with '.FromSql(...)' retaining the convenience of object mapping. Interpolated queries use string interpolation API to convert them to parametrized queries that are injection-safe under the hood.

https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

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

#57

Post by yurishimo »

nprateem wrote: post #29

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). I…

It depends on what kind of app you’re building. The Django UI could be okay for your business use case, but for many businesses, it is not. If I have to write the entire admin UI for some specific business reasons/workflow, then I might as well dogfood those components for the needs of our dev team.

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

#58

Post by exceptione »

santiagobasulto wrote: post #41

I think Django's ORM is just AMAZING. And as with every other tool, it has to be used wisely. First, it let's you get started quickly and prototype. You can write unit tests, make sure everything is working as expected, then count queries and make sure you're being efficient with your SQL engine. Second, and even more importantly, it's crucial in the definition of the app and the Schema. Thinking in high level "class…

There is one part in me that says to not destroy your positive mood, there is another part in me that wishes to yell at the pythonistas in general to look outside the Python world.

Too often I come across Python projects that are hyped and when I dive into it I find it rather underwhelming to say it politely. Invariably it turns out that those people don´t know any other language than Python.

I see that as a general problem; Python is the language for beginners this day with an endless amount of tutorials, but it seems lots of those starters don´t get to have a look outside the Python world. I fear this is getting an even bigger problem because AI models are trained on a vast range of Python, not because it is better, but simply because it is the PHP of these days.

I don´t mean to imply that I know you have that "narrow profile".

I agree that the value in Python is for quick prototypes in case you know Python well. Outside of that (at the risk of a language war), I think one does better look into modern .net core or the JVM for a general purpose, high quality and highly efficient language/platform.

On the topic of ORM I think EF Core (.net core) and Doctrine (php) is strictly better.

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

#59

Post by JodieBenitez »

bitexploder wrote: post #26
choilive wrote: post #7

Earlier quoted context omitted.

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.

I don't know, the declarative API is awkward. I get SQLAlchemy is quality software but I found DX poor.

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

#60

Post by juahan »

exceptione wrote: post #58
santiagobasulto wrote: post #41

I think Django's ORM is just AMAZING. And as with every other tool, it has to be used wisely. First, it let's you get started quickly and prototype. You can write unit tests, make sure everything is working as expected, then count queries and make sure you're being efficient with your SQL engine. Second, and even more importantly, it's crucial in the definition of the app and the Schema. Thinking in high level "class…

There is one part in me that says to not destroy your positive mood, there is another part in me that wishes to yell at the pythonistas in general to look outside the Python world. Too often I come across Python projects that are hyped and when I dive into it I find it rather underwhelming to say it politely. Invariably it turns out that those people don´t know any other language than Python. I see that as a general…

How are those better?
Post reply on HN