Hacker News Reader

Comment by patates | Hacker News Reader

Last week I was trying develop a quick prototype, and instead of setting up a C# project, I tried Django.

At first, everything seemed super easy, but later I hit so many road-blocks that I had to give up (For example defining a self-referential m2m relationship with a custom join table, and getting it working on the admin site).

Don't people really have such problems with it? It really feels like a huge burden when you do things outside the happy-path. Also the documentation is indeed superb but you also hit a lot of outdated info when searching the web.

View on HN

There's a "through" argument for the ManyToManyField that allows you to specify a custom model to track relationships.

Then there's InlineModelAdmin that allows you to integrate your relationships in the admin.

You gave up instead of reading the docs.

I used Django for 4 years, their ORM is a mess imo. I wouldn't expect someone new to it to be able to discover how to do this after a couple of hours of reading.

That might be a matter of taste, or which ORM you've used previously. Personally I think it's the only sort of okay ORM, besides Go's sqlx, which is barely an ORM.

You do need to have the documentation handy, and writing efficient queries can be tricky, but it is the ORM that makes the most sense to me, and the easiest to get started with.

Have you tried SqlAlchemy? I liked that it felt a lot more like writing sql, whereas Django feels like trying to force a different model on top.

The ORM is great ... but is a question of taste/previous experiences. Once you start playing with annotations, DB-side functions and subqueries, it is very nice.

Only frustration I have is the power/possibilities of mysql (which I use 99% of the time for various reasons) versus postgre. The latter seems far better and advanced, and it does reflect in the ORM.

But wait, this isn't linked to django, is it? :-)

I agree. I can generally do what I need to with the ORM, except in extreme cases where you probably should be writing custom SQL anyway. I do fight with Subquery and OuterRef now and then, thinking OuterRef isn't being used in a Subquery when it is, but a little debugging usually resolves that.

The one thing I really wish Django had after all these years is multi-column PK support. I bring it up every time I see a thread about Django, hoping the devs or an open-source contributor will take it on. But after 10+ years, the open ticket just keeps passed on and I don't know that I have the skills to do it myself.

care to elaborate on that "multi-column PK support" please? :)

Django currently requires that every table have a _single_ primary key column. You can have a unique multi-column index, but you _also_ need to have a single primary key column, which sometimes makes working with existing databases tricky or inefficient.

It's Django's oldest open ticket, from August 2005: https://code.djangoproject.com/ticket/373

The trick is how do you group those columns together in a way that stays compatible with the rest of the framework.

Here's a 2015 proposal "DEP 191" for how to make it work:

- https://github.com/django/deps/blob/main/draft/0191-composit...

Basically, the multi-columns end up needing to be exposed as a single python object (CompositeField) to stay compatible with the rest of the framework, but do changes to the individual "subfields" on the row-object need to be kept in sync (data binding) with the CompositeField-object and maybe vice-versa? Now we need an "Observer" (which Django doesn't currently have) to watch for changes to fields, etc. So a lot of new concepts end up needing to be introduced to make this happen. And it needs to work with migrations and serialization while trying to maintain backward-compatibility.

Here's rough code (again, from 2015):

https://github.com/django/django/pull/4553

Since 2015, Django now has class-based-indexes which should make things slightly easier:

https://docs.djangoproject.com/en/stable/ref/models/indexes/

Maybe at least the Observables could get merged in as a first-step which would make the remaining work a little easier?

I see, what a hoot! :-)

Great explanation. Thanks for taking the time to write it up and link to relevant posts. Any exposure can only help.

When you're a Django beginner, yes, it can be annoying to go from something that's just super easy to having to stitch together something yourself. I'm not sure what exactly causes this feeling, but I did learn that you need to have the right perspective on some things and either let it go or find some other way.

For instance, in my experience the admin site is best thought of as glorified DB UI. If you need something more than what it can offer out of the box, you should switch to coding it yourself, or live with a quick hack.

I think that most of the time, Django just gets out of the way. At least if you stay away from the inheritance spaghetti that is class-based views. Use the functions, Luke. :)

> either let it go or find some other way.

With Django as soon as I have anything to do with a database I seem to hit this with the ORM. So I start working around it. Next thing you know it all seems to fall apart because of how coupled the rest of the application is to Django's assumptions about views and entities in the DB.

So "You gave up instead of reading the docs.": I go back to flask, or recently FastApi where you have to figure your schemas and access patterns out for yourself in advance instead of building thorough and deep knowledge on how to deactivate parts of Django when they become redundant. Opinion my own, results may vary, IANA your dev, etc

Flask with something like Flask-Security or Flask-Admin is my go-to

> For instance, in my experience the admin site is best thought of as glorified DB UI. If you need something more than what it can offer out of the box, you should switch to coding it yourself, or live with a quick hack.

Agreed. My biggest Django headaches ultimately resulted from me trying to make the admin console do more than it's meant to do.

There are certainly limitations to the admin console/module, but it is still rather amazing. The amount of stuff that it will allow you to do is pretty impressive.

Sure, you easily get into a situation where you're out of luck using the admin module, but there are also entire classes of problems that can be solved using only the build in admin functionality.

Yeah, the trick I've learned is to design my models in a way that I know will work well in the admin. It's a little backwards, but it means I can keep using the admin.

For most frameworks,etc... I find that things get harder as the project grows in size and more code is added. Strangely, I find the complete opposite with Django. I find that adding new features and apps in my day job is easy and I barely even think that I'm using Django, but trying to start a hobby project with it is initially a bit of a nightmare

That being said, weighing up the good with the bad, its still my favourite web framework

Not my experience. I inherited two Django projects, and adding features is quite cumbersome. I had to add one boolean switch which Django only has to pass from an Angular form to a template, and I had to alter the code in 7 places (one of which is the Angular code). It's just not suitable for REST-like access from a front-end, nor for data that's not a tree, nor for heavy processing: I ended up pulling all kinds of tricks to keep processing time limited, and at a few points resorted to writing SQL queries. It's pretty heavy on CPU and memory.

> It's just not suitable for REST-like access from a front-end, nor for data that's not a tree, nor for heavy processing

It obviously depends very much on your opinion on what defines "heavy processing", but we do all those things without too much trouble. Obviously we may, and probably do, do things differently to you (we dont use Angular for example, though that seems like it wouldnt be too big a factor) so YMMV, but yeh, for us its been pretty solid

That use case has been easily discovered in the docs for several years at least

Could you please point to me where? Custom join table, check. Self-referencing m2m, check. Setting up admin for it?

It's like any other table/model so you'd just go to the docs for the admin stuff and go from there

You can assume that I have the decency to check the docs before I even ask on Stack Overflow, let alone complain about it on HN :)

I did follow the docs, it gave errors for one reason after another, and I don't have the time to dive into Django internals anymore when stuff like that keeps happening. From there came my opinion that non-happy path is not very much supported.

I am usually a symfony developer, but have also worked for some clients projects which needed to be done with ASP.Net MVC, and I would agree with you that Django, I think, is the most limited one. If you are used to work on a complete and extensible frameworks. But I also think that python is not really made for making extensible code, as without typing or interfaces it gets really hard to create something solid

What do you mean with custom join table? Self-referential m2m works fine im my experience.

I think he refers to that you can customize the table Django sets up to handle the m2m which normally is "hidden" (i.e. you don't define it explicitly). But if you want to track for example the time a relation was set up, you can define a custom m2m object that contains a DateTime.

Django Admin is not really designed to be an all-encompassing admin solution I've found, it's a good start but normally you design your own admin console anyway using your API so I've not cared that much about those shortcomings.

Interestingly, I also considered doing a recent prototype in C#, but opted to try Django. I didn't hit any roadblocks like this though, overall the experience was pretty nice. The fact that the Django admin site allows you to get instant CRUD functionality from your models with almost zero effort is something I've not seen in other web frameworks (maybe nest.js gets close, but I'd love to see a .NET equivalent to the admin site).

I had the same impression when I tried it a few years ago (also coming from a .NET background).

I never got the chance to use it professionally so I didn’t get the “fully under control” feeling I get when working with .NET, thus never had the confidence to push for it in my company/clients out of fear of not being able to fix whatever went wrong.

Kind of regretting not making the switch back then, but well, nowadays .NET is good enough. Never managed to squeeze as much productivity as I did with those small college projects back then.

I think with Django, you should pick the parts that you like and not touch the others. Then, design your application around the limitations of Django.

If you have a data model that requires a self-referential m2m relationship, think if there is another way to model it ("collection" object), or don't tell Django about it.

OT, but how do you feel C# (w/ ASP and EF, I suppose?) stacks up in productivity and TTM? What's the kind of problem you run into where you start feeling like you're not working on the domain but on side details?

There’s this enterprise mindset surrounding .NET where it feels like you need a lot of boilerplate to do anything, all for the sake of testability. I think I just dislike working with interfaces.

I didn't want to deal with the front-end. It took me, however, less time to create a custom front-end (for a particular task) than dealing with Django-admin. YMMV.

With Entity Framework and Dapper, I don't think I can be more productive at the back-end in any other stack than I'm with .NET. If I have a couple of models, I'm usually done with basic CRUD, including REST controllers under an hour.

For the front-end, I wrote a couple of purpose-built generators for now.

Reply on news.ycombinator.com