3 ms·

I think the first objection one would raise is that you don't need an ORM at all. It all depends on the application, of course, but ORM means giving up a lot o

I think the first objection one would raise is that you don't need an ORM at all. It all depends on the application, of course, but ORM means giving up a lot of control (and transparency, and understanding) of your database in exchange for a few shortcuts regarding things like M:M links.

odonnellryan 10y ago
IMO, if you're using an ORM because you want many-to-many to work in a neat way, then you're using an ORM for the wrong reasons. Use an ORM because tools like this: https://marshmallow.readthedocs.io/en/latest/ https://marshmallow.readthedocs.io/en/latest/ work really well with it. And tools for migrations: https://sqlalchemy-migrate.readthedocs.io/en/latest/ https://sqlalchemy-migrate.readthedocs.io/en/latest/ start to make sense in your code. You don't need an ORM to do either of those things, but it makes things a hell of a lot more organized. Makes the database easy to understand from your code. Makes things like "testing from a blank database" really nice. You don't ever _need_ an ORM, but for 90% of projects you'll use Flask and a Database for, it makes your life a lot nicer.
- joeclark77 10y ago
  I actually wrote a blog post about my experimentation with ORM (here: https://joeclark.svbtle.com/understanding-the-m-in-mvc https://joeclark.svbtle.com/understanding-the-m-in-mvc). From the viewpoint of a database geek, somebody who cares about his database, those gadgets you linked are further reasons to dislike ORM, because they do more of what ORM does: take away transparency and control in exchange for "shortcuts". And what happens when those tools fail? ("migrate" is particularly screwy). No, it's a matter of philosophy. The newbie who has learned to code without ever being taught SQL, and the employee of an "agile" app sweatshop who doesn't care about the quality of his code or data, may prefer ORM for its' quick-and-dirtiness, or may use it by default because he knows no better way. I'm not saying that's wrong, but, there are other philosophies. There is the whole "craftsmanship" idea out there, that we should actually care about making things well. Jobs and Wozniak for example supposedly were adamant that the insides of Apple computers were designed well. If you care about your database and want to use special features like triggers, procedures, recursive queries in Postgres, etc., then ORM is about as helpful as clamshell packaging.
  - odonnellryan 10y ago
    This is a good point, but it can definitely be applied to any abstraction. I don't think ORMs are the best use of abstraction, but I think they're far from the worst use. For most applications they let you do a lot more a lot quicker without knowing a lot of SQL. > And what happens when those tools fail? I haven't used any of these tools that don't let me fall back on raw SQL or writing my own migration in SQL and including it in my code (outside of the DB). So, I haven't had this problem, honestly! Most DB problems I've had are related to _design_. There is an argument there to be had: "Do ORMs encourage bad database design?" but it's a different topic, in my opinion. > There is the whole "craftsmanship" idea out there, that we should actually care about making things well. Making a website is a completely different process than making a chair, or remodeling a kitchen, or designing hardware for a computer. I absolutely make technology that is great, and I do take pride in my work, but if I didn't use an ORM it'd take me much longer to make: and the application would be much less maintainable. > If you care about your database and want to use special features like triggers, procedures, recursive queries in Postgres, etc., then ORM is about as helpful as clamshell packaging. I use all these things all the time. I've created migrations in Django to create my Postgres FTS trigger function. Now all these raw-SQL migrations are stored very nicely in their own space, and in version control. And it's just like I typed them into the SQL prompt: but I can just look in my codebase and see what I did :) You can'd even do sub-selects nicely in Django ORM, forget recursive queries. But you can use raw SQL when you need it!
git-pull 10y ago
And I used to think like that. As if I was giving up potential. So I went through this SQLAlchemy core phase (http://docs.sqlalchemy.org/en/latest/core/tutorial.html http://docs.sqlalchemy.org/en/latest/core/tutorial.html). Though, never back to writing raw SQL, but I did some of that back in 2002-2003. And despite being challenged by colleagues skeptical of ORM's, I've yet to see a shortcoming for using an ORM in web development frameworks in python. In fact I'm coming short on a value equation where it'd be more secure / efficient / readable without at least a query builder. > but ORM means giving up a lot of control What control is being lost, specifically? > (and transparency, and understanding) Highly recommend Django in Depth by James Bennett at PyCon 2015. https://www.youtube.com/watch?v=tkwZ1jG3XgA https://www.youtube.com/watch?v=tkwZ1jG3XgA Also, try out printing the .query of the QuerySet: print(MyUser.objects.all().query) SELECT "core_myuser"."id", "core_myuser"."password", "core_myuser"."last_login", "core_myuser"."is_superuser", "core_myuser"."username", "core_myuser"."email", "core_myuser"."is_active", "core_myuser"."is_admin" FROM "core_myuser" And Q(), https://docs.djangoproject.com/en/1.11/topics/db/queries/#complex-lookups-with-q-objects https://docs.djangoproject.com/en/1.11/topics/db/queries/#co..., .extra(), https://docs.djangoproject.com/en/1.11/ref/models/querysets/#extra https://docs.djangoproject.com/en/1.11/ref/models/querysets/..., and finally raw SQL queries https://docs.djangoproject.com/en/1.11/topics/db/sql/ https://docs.djangoproject.com/en/1.11/topics/db/sql/. > of your database in exchange for a few shortcuts regarding things like M:M links. Maybe a few other benefits: helps with readability, consistent with OOP in python. Works across SQL dialects. Prevents mistakes, since those relationships are common. Getting clear and consistent access to common data retrieval and updating.

odonnellryan 10y ago

IMO, if you're using an ORM because you want many-to-many to work in a neat way, then you're using an ORM for the wrong reasons. Use an ORM because tools like this: https://marshmallow.readthedocs.io/en/latest/ https://marshmallow.readthedocs.io/en/latest/ work really well with it. And tools for migrations: https://sqlalchemy-migrate.readthedocs.io/en/latest/ https://sqlalchemy-migrate.readthedocs.io/en/latest/ start to make sense in your code. You don't need an ORM to do either of those things, but it makes things a hell of a lot more organized. Makes the database easy to understand from your code. Makes things like "testing from a blank database" really nice. You don't ever _need_ an ORM, but for 90% of projects you'll use Flask and a Database for, it makes your life a lot nicer.

joeclark77 10y ago
I actually wrote a blog post about my experimentation with ORM (here: https://joeclark.svbtle.com/understanding-the-m-in-mvc https://joeclark.svbtle.com/understanding-the-m-in-mvc). From the viewpoint of a database geek, somebody who cares about his database, those gadgets you linked are further reasons to dislike ORM, because they do more of what ORM does: take away transparency and control in exchange for "shortcuts". And what happens when those tools fail? ("migrate" is particularly screwy). No, it's a matter of philosophy. The newbie who has learned to code without ever being taught SQL, and the employee of an "agile" app sweatshop who doesn't care about the quality of his code or data, may prefer ORM for its' quick-and-dirtiness, or may use it by default because he knows no better way. I'm not saying that's wrong, but, there are other philosophies. There is the whole "craftsmanship" idea out there, that we should actually care about making things well. Jobs and Wozniak for example supposedly were adamant that the insides of Apple computers were designed well. If you care about your database and want to use special features like triggers, procedures, recursive queries in Postgres, etc., then ORM is about as helpful as clamshell packaging.
- odonnellryan 10y ago
  This is a good point, but it can definitely be applied to any abstraction. I don't think ORMs are the best use of abstraction, but I think they're far from the worst use. For most applications they let you do a lot more a lot quicker without knowing a lot of SQL. > And what happens when those tools fail? I haven't used any of these tools that don't let me fall back on raw SQL or writing my own migration in SQL and including it in my code (outside of the DB). So, I haven't had this problem, honestly! Most DB problems I've had are related to _design_. There is an argument there to be had: "Do ORMs encourage bad database design?" but it's a different topic, in my opinion. > There is the whole "craftsmanship" idea out there, that we should actually care about making things well. Making a website is a completely different process than making a chair, or remodeling a kitchen, or designing hardware for a computer. I absolutely make technology that is great, and I do take pride in my work, but if I didn't use an ORM it'd take me much longer to make: and the application would be much less maintainable. > If you care about your database and want to use special features like triggers, procedures, recursive queries in Postgres, etc., then ORM is about as helpful as clamshell packaging. I use all these things all the time. I've created migrations in Django to create my Postgres FTS trigger function. Now all these raw-SQL migrations are stored very nicely in their own space, and in version control. And it's just like I typed them into the SQL prompt: but I can just look in my codebase and see what I did :) You can'd even do sub-selects nicely in Django ORM, forget recursive queries. But you can use raw SQL when you need it!

git-pull 10y ago

And I used to think like that. As if I was giving up potential. So I went through this SQLAlchemy core phase (http://docs.sqlalchemy.org/en/latest/core/tutorial.html http://docs.sqlalchemy.org/en/latest/core/tutorial.html). Though, never back to writing raw SQL, but I did some of that back in 2002-2003. And despite being challenged by colleagues skeptical of ORM's, I've yet to see a shortcoming for using an ORM in web development frameworks in python. In fact I'm coming short on a value equation where it'd be more secure / efficient / readable without at least a query builder. > but ORM means giving up a lot of control What control is being lost, specifically? > (and transparency, and understanding) Highly recommend Django in Depth by James Bennett at PyCon 2015. https://www.youtube.com/watch?v=tkwZ1jG3XgA https://www.youtube.com/watch?v=tkwZ1jG3XgA Also, try out printing the .query of the QuerySet: print(MyUser.objects.all().query) SELECT "core_myuser"."id", "core_myuser"."password", "core_myuser"."last_login", "core_myuser"."is_superuser", "core_myuser"."username", "core_myuser"."email", "core_myuser"."is_active", "core_myuser"."is_admin" FROM "core_myuser" And Q(), https://docs.djangoproject.com/en/1.11/topics/db/queries/#complex-lookups-with-q-objects https://docs.djangoproject.com/en/1.11/topics/db/queries/#co..., .extra(), https://docs.djangoproject.com/en/1.11/ref/models/querysets/#extra https://docs.djangoproject.com/en/1.11/ref/models/querysets/..., and finally raw SQL queries https://docs.djangoproject.com/en/1.11/topics/db/sql/ https://docs.djangoproject.com/en/1.11/topics/db/sql/. > of your database in exchange for a few shortcuts regarding things like M:M links. Maybe a few other benefits: helps with readability, consistent with OOP in python. Works across SQL dialects. Prevents mistakes, since those relationships are common. Getting clear and consistent access to common data retrieval and updating.