Is Django's ORM even supported outside Django sites? I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.
I have made this tiny module to use it wherever I want it.
Django: One ORM to rule all databases
51–60 of 85 posts
Re: Django: One ORM to rule all databases
#52I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
SQLAlchemy was just more expressive in previous years and was a requirement for projects that had more advanced data types and didn't want to use raw sql (or build their own ORM pieces). Django is sealing its fate with the opposition to type annotations. I hope sqlc continues to grow on the Python side because it is wonderful in Go. alembic is also much better than Django's migrations for the ability to expose the tr…
Yeah the Django typing situation is a bit sad. It's obvious that if Django wants to scale to larger teams types would help a lot, especially around getting things like string-field-named annotated query fields onto objects typechecking.
Re: Django: One ORM to rule all databases
#53I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
Fun story: I once worked on a C piece of industrial software that was running on AIX 3.x to 6.x; the goal was to have a nicer (web) status monitoring UI as well as being able to implement stuff in a "safer" language and onboard more people. The main problem was that the "database" was IBM C-ISAM. Think MySQL MyISAM tables, except don't even dream about SQL, you interact directly with the internal primitives through a…
I used Django to give a legacy java application an instant admin UI and REST interface. Django was able to introspect the database to generate the models, and even for an extremely crufty DB it worked reasonably well.
Re: Django: One ORM to rule all databases
#54Earlier quoted context omitted.
My problems with ORMs is that they are a solution in search of a problem most of the time. We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.
> We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine. ORMs are not an abstraction to interface with the DBMS. They are an abstraction to map the data in your database to objects in your code and vice versa. It's literally in the name. Feels like a lot of anti-ORM sentiment originates from people who literally don't know what the acronym means.
> They are an abstraction to map the data in your database to objects in your code and vice versa.
Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language.
Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.
Re: Django: One ORM to rule all databases
#55ORMs are one of those topics that get hotly debated for little reason IMO. ORMs like almost everything else in SWE they are _tool_. It's not a law or a prescription. It's not mandatory. ORMs are fine for 99% of cases. When it isn't fine use raw sql, no one is going to mock you, no one is going to jeer at you. Most times ORMs are fine, sometimes they are not.
My problems with ORMs is that they are a solution in search of a problem most of the time. We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.
Mostly, I think, the problem is SQL injection, and raw SQL is a great place for people to forget to escape their strings.
Re: Django: One ORM to rule all databases
#56Earlier quoted context omitted.
> We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine. ORMs are not an abstraction to interface with the DBMS. They are an abstraction to map the data in your database to objects in your code and vice versa. It's literally in the name. Feels like a lot of anti-ORM sentiment originates from people who literally don't know what the acronym means.
> They are an abstraction to map the data in your database to objects in your code and vice versa. Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language. Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.
Okay, so what's the round peg that goes in the round hole, here? Forgetting about objects and just passing around dicts or whatever with no type information?
Re: Django: One ORM to rule all databases
#57Earlier quoted context omitted.
My problems with ORMs is that they are a solution in search of a problem most of the time. We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.
Mostly, I think, the problem is SQL injection, and raw SQL is a great place for people to forget to escape their strings.
ORM's are not the only solution to SQL injection, pyscopg for example handles string escaping etc for you.
Re: Django: One ORM to rule all databases
#58Earlier quoted context omitted.
> They are an abstraction to map the data in your database to objects in your code and vice versa. Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language. Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.
Okay, so what's the round peg that goes in the round hole, here? Forgetting about objects and just passing around dicts or whatever with no type information?
> Forgetting about objects and just passing around dicts or whatever with no type information?
Why would you need to drop the type information when you stop using hierarchical structures for your data?
Re: Django: One ORM to rule all databases
#59I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
I prefer working with Django ORM too by a large margin. But I think it's more opiniated than SQLAlchemy, which may be why SQLAlchemy is considered the reference (well.... this and the fact that Django ORM is not a standalone lib). It's great if your use case fits to it but if not, SQLAlchemy probably gives you more adaptability. But yes, Django ORM any day... or just no ORM at all.
SQLAlchemy has one strongly-held opinion, that there should be a 1:1 mapping between objects in a database and in memory. So if you query the database then modify the result, the change will automatically also be made in the DB.
I strongly dislike this, since you always have to be careful not to make some unwanted change. When checking permissions, you have to check before you modify the object. You can't modify it and then run some permission checker. You also can't easily keep the old version around.
Sadly it seems most ORMs follow this style, and that Django's is the odd one out.
Re: Django: One ORM to rule all databases
#60I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
Are you saying you'd start a new project with alembic/sqlalchemy nowadays?