Hacker News Reader

Hacker News

Comment by BiteCode_dev | Hacker News Reader

Parent Full thread

BiteCode_dev

This article misses the point of the django orm and migration system completly.

They are meant to allow for the dev of an ecosystem.

This is why you have so many django plugins, and why they are so easy to integrate and play together.

This is why it's easy to have a dev envs, tests, signals and api generation with django.

It trades performances and flexibility for this. It's nothing more than a classic technical compromise.

You may need raw sql later on in your django project. But if you feel like starting with it, just go with flask. Django makes no sense.

View on HN

The other funny thing is how easy it is to write migrations in Python via the RunPython capabilities of the Django ORM you can migrate data over. I've yet to need to write any SQL aside from stored procedures and Database Views.

You can even export all the contents of your DB to JSON or YAML and import it in Django, so you probably very well could go from SQLite to MySQL / Postgres if you really wanted to.

Edit:

The other actually funny thing is, Django doesn't force you to use its own ORM. You can write code that doesn't use its ORM. You can override anything and everything.

> how easy it is to write migrations in Python via the RunPython capabilities of the Django ORM you can migrate data over.

Yes! This functionality is extremely useful in a number of cases and isn't all that discoverable. At least in my experience, devs often don't learn about it until they've spent at least a bit of time working on a Django project. Once you get the (basic) syntax down it's quite handy.

> You can write code that doesn't use its ORM.

You can, but what's the point using Django then? Everything is built around the ORM API, that's how admin is automatically generating pages, etc, etc. You lose the main advantage of Django if you don't use it.

ASP .NET Has the same issue, but you could always override the admin bits. If you really want another library to manage Django's database usage, you can go to town, nobody has bothered coding alternatives because the ORM is sufficient. Web frameworks are not what you use if you're even concerned with micro managing how you access a database, web microframeworks on the other hand are designed for that level of detail. Something like CherryPy or Flask is more what you'd want in that case.

For me it's too much easy to write them with sql or plpgsql.. and later I can use them from node, rust, go.. or whatever.. for me the dB (the model) it's the source of thruth that will lasts.. independent of the language that interacts with it...

Also the problem gets worst if you add to the mix something like elastic search. That it also has it's own schema and it's also has to be migrated..

But now you've got the issue that the code needs to match the DB. Django takes care of this for you. It's really quite nice.

That's the trade-off if you decouple the dB from the web framework you have to take care of both.. :) anyway, I prefer to trust the dB (real data on it) that a bunch of complicated things on the Django side.. (I suspect that happened something similar to me when I started reviewing crazy (shoot your food) class based elaborations..

You can always tell Django's ORM not to manage any of your data and write all your queries. You can also tell Django to give you the query it generates, tweak it (if / as necessary) and run from there.

Agree. This article misses the use case of people using third party apps with migrations. For example. The Wagtail content management team can create migrations that can be applied to MySQL and Postgres databases. Not sure if that is possible writing SQL files.

Django is incredibly flexible, even if you decide not to use the ORM, or even to just use part of it and write a lot of raw sql, Django is a great choice. It can still be a great choice.

Or even if you ditch the SQL database entirely and use Elasticsearch or some weird custom back-end.

And then (with elastic) why you will use a synchronous web framework ;)

Synchronous web frameworks have been powering some of the largest websites on the internet for decades.

That said, Django is actively working toward async views and ORM. It's happening.

In fact, it was just released a few days ago.

Then you still need to upgrade Django.. (had seen so many sprint points spent on it.. :/)

I agree with you but I think Sqlalchemy/alembic do the compromises better than Django ORM

With Django I always ended up hitting brick walls and ugly hacks. Whereas Sqlalchemy more easily fit in any use case that I had over the years, mainly because of it having multiple layers of abstraction so I can choose and mix as applicable. Learning curve is a bit steeper i admit.

I haven't used Sqlalchemy drop in replacement for Django ORM yet, but would consider it for a future project.

I think one issue with SQLAlchemy is that, somehow, they are the worst of all worlds. They have multiple ways to run queries (iirc, the "model" way, the non-model way, and the raw way) but it is all the "model" way underneath so you end up with all kind of weird hacks if you don't want to use Python as the source of truth (i.e. if you run a query, have no data model in Python but want to turn the data into a dictionary). It seemed like a very flabby codebase (i.e. they started out doing X, and tried to add stuff on top...lots of classes that appear to do the same thing).

The only ORM that I have used that handled more complex stuff well was Jooq (Java). Having your database as the source of truth (and running a script to update Java Objects) works far better than the SQLAlchemy approach. I use Django now for a simple app but I used both Jooq and SQLAlchemy on something more complex (the issue was references to parts of the data models across components), and the former was brilliant (although learning curve) and the latter was just awful. I don't think SQLAlchemy docs are good either (again, started out as X and they just kept adding and adding).

That is just my experience. I used Django right now, there are no crazy cross-cutting concerns between components, and it works fine.

It is the other way around. The ORM sits on top of core, the sql abstraction.

This separation is what I like about it, if I know how to do something in SQL I can use the tools sqla provides and it maps very close to 1:1. Or I can use a more ORM driven approach similar to what Django does. I can adapt it over time as the project evolves.

But yes to write the queries in Python and not raw strings, you need to have either a Table or ORM Model defined, which you could generate from the database [1]. But I admit, except for some scripts, I have never used it where Python wasn't the source of truth, so don't know what it all involves.

I don't know about very old versions of SQLAlchemy, but at least in the last 4.5 years since I'm using it, I have been much happier with it for medium sized projects over any other similar tool in Python I have tried because of this flexibility

[1] Edit: Or use reflection to load schema information from the database

  >>> messages = Table('messages', meta, autoload=True, autoload_with=engine)
  >>> [c.name for c in messages.columns]
  ['message_id', 'message_name', 'date']

That's the nice thing around sqlalchemy, it's a lib, a toolkit.. you can start using it on whatever postgresql schema you found.. Django can't only work if things are done like it wants... You will also use Django for an old legacy PHP project with postgresql? You can use SA for taking on it.

You can absolutely use Django for an old Php project with PostgreSQL, just fake the initial migrations and it'll pick up right where PHP left off with the same schema.

Many of the points made apply equally to Flask/SQLAlchemy or any other framework (Rails, ...).

They optimise the wrong things and decrease security.

All of them optimize for different things (E.g. SQLalchemy and Django have very different philosophies), so are they all wrong? What should they focus on instead?

> They optimise the wrong things and decrease security.

They're not meant to optimize for every edge case, they're meant to be as generic as sanely possible.

Reply on news.ycombinator.com