7 ms·

Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feel

by h4kor 3y ago

Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility more often?

jedi_stannis 3y ago
They switched their versioning scheme after the 1.x. https://docs.djangoproject.com/en/dev/internals/release-process/ https://docs.djangoproject.com/en/dev/internals/release-proc...
freedomben 3y ago
Have you worked with ActiveRecord or Ecto? Just wondering for framing your comment
- ralmidani 3y ago
  Not who you’re asking, but I’ve used all 3. I think in terms of query interface you can’t go wrong with any of them. In fact, I like Ecto the most because of its separation between the concept of a “Query” (super flexible and composable) vs. a “Repo” (the module where you call an actual database operation). This helps you avoid hitting the database until you’re sure you want to. Where Django’s ORM shines is in the modeling stage: classes in models.py are your single source of truth, relationships only need to be defined once, no separate “schema” file, and most of the time migrations can be generated automatically. It’s truly top-notch.
  - robertlagrant 3y ago
    I think SQLAlchemy is better, personally. Still just model files, but it's data mapper pattern means you won't be hitting all the issues people do with active record.
- h4kor 3y ago
  I briefly used Ecto when trying out Phoenix framework but have not worked enough with it to form an opinion.
DarkNova6 3y ago
> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...
- eYrKEC2 3y ago
  ORM's always abstract away details, but you monitor for slow queries and slow endpoints and then just fix the issues when they crop up.
- Alex3917 3y ago
  > Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right... FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.
- belorn 3y ago
  There does seem to be a natural conflict between large data with hierarchical structure and the generally flat lists and dictionaries of Python, that quickly leads to poor performance. It usually only takes a few foreign keys to create an exponential number of queries. But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic page will be so noticeable slow that one has to go through the queries and use things like select related. Occasionally it is also better to just grab everything into memory and do operations in Python, rather than force the data manipulation to be done as a single database query. It is a good tool for its purpose, but it is no replacement for SQL knowledge when working with complex relational databases.
  - h4kor 3y ago
    Yes you do have to work on your queries to keep them fast with growing complexity. Django also has a usable intermediate API to construct your queries, instead of writing raw SQL. Nice feature to have if you don't want to commit to a specific database yet. And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.
sarahboyce 3y ago
The release process is time-based as to roughly every 8 months[1] with X.0, X.1, and X.2 (LTS). This is mostly to communicate which release has long term support. The deprecation policy[2] is taken very seriously and Django doesn't opt to break things if it can. Recently there was a very interesting discussion[3] between the Fellows as to whether the version numbering is confusing as this doesn't follow the same pattern as other libraries. 1: https://docs.djangoproject.com/en/dev/internals/release-process/#release-cadence https://docs.djangoproject.com/en/dev/internals/release-proc... 2: https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy https://docs.djangoproject.com/en/dev/internals/release-proc... 3: https://fosstodon.org/@carlton/111300877531721385 https://fosstodon.org/@carlton/111300877531721385
adastra22 3y ago
Similar to bitcoin, they changed to a time-based versioning scheme. Major releases don't indicated that they DID break compatibility, but that they MIGHT HAVE, and more importantly prior versions are no longer supported. Effectively the same as a LTS release.
pmontra 3y ago
The ORM is OK as long as you refrain from using any inheritance. If you do, the database becomes a mess quickly and only that very Django app will be able to read and write to it (including manage.py shell). Anything else, other apps in any language or a SQL client, will be lost in a sea of tables and joins. I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. The database is a nightmare. The other one was developed thinking table by table and creating models that mimic the tables we want to have. That's a database we can also deal with from other apps and tools.
- dd82 3y ago
  tbh, any OOP paradigms used with db tables will end up in a clusterf*ck.
- NoGravitas 3y ago
  I've found inheritance to be a problem with pretty much any ORM I've used extensively (Django, Hibernate, NHibernate, Entity Framework). It helps to design your OOP model with that in mind; having no more than one level of inheritance, and using inheritance only to supplement a set of common records seem to be good enough rules of thumb.

by h4kor 3y ago

jedi_stannis 3y ago

They switched their versioning scheme after the 1.x. https://docs.djangoproject.com/en/dev/internals/release-process/ https://docs.djangoproject.com/en/dev/internals/release-proc...

freedomben 3y ago

Have you worked with ActiveRecord or Ecto? Just wondering for framing your comment

ralmidani 3y ago
Not who you’re asking, but I’ve used all 3. I think in terms of query interface you can’t go wrong with any of them. In fact, I like Ecto the most because of its separation between the concept of a “Query” (super flexible and composable) vs. a “Repo” (the module where you call an actual database operation). This helps you avoid hitting the database until you’re sure you want to. Where Django’s ORM shines is in the modeling stage: classes in models.py are your single source of truth, relationships only need to be defined once, no separate “schema” file, and most of the time migrations can be generated automatically. It’s truly top-notch.
- robertlagrant 3y ago
  I think SQLAlchemy is better, personally. Still just model files, but it's data mapper pattern means you won't be hitting all the issues people do with active record.
h4kor 3y ago
I briefly used Ecto when trying out Phoenix framework but have not worked enough with it to form an opinion.

DarkNova6 3y ago

> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...

eYrKEC2 3y ago
ORM's always abstract away details, but you monitor for slow queries and slow endpoints and then just fix the issues when they crop up.
Alex3917 3y ago
> Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right... FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.
belorn 3y ago
There does seem to be a natural conflict between large data with hierarchical structure and the generally flat lists and dictionaries of Python, that quickly leads to poor performance. It usually only takes a few foreign keys to create an exponential number of queries. But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic page will be so noticeable slow that one has to go through the queries and use things like select related. Occasionally it is also better to just grab everything into memory and do operations in Python, rather than force the data manipulation to be done as a single database query. It is a good tool for its purpose, but it is no replacement for SQL knowledge when working with complex relational databases.
- h4kor 3y ago
  Yes you do have to work on your queries to keep them fast with growing complexity. Django also has a usable intermediate API to construct your queries, instead of writing raw SQL. Nice feature to have if you don't want to commit to a specific database yet. And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.

sarahboyce 3y ago

The release process is time-based as to roughly every 8 months[1] with X.0, X.1, and X.2 (LTS). This is mostly to communicate which release has long term support. The deprecation policy[2] is taken very seriously and Django doesn't opt to break things if it can. Recently there was a very interesting discussion[3] between the Fellows as to whether the version numbering is confusing as this doesn't follow the same pattern as other libraries. 1: https://docs.djangoproject.com/en/dev/internals/release-process/#release-cadence https://docs.djangoproject.com/en/dev/internals/release-proc... 2: https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy https://docs.djangoproject.com/en/dev/internals/release-proc... 3: https://fosstodon.org/@carlton/111300877531721385 https://fosstodon.org/@carlton/111300877531721385

adastra22 3y ago

Similar to bitcoin, they changed to a time-based versioning scheme. Major releases don't indicated that they DID break compatibility, but that they MIGHT HAVE, and more importantly prior versions are no longer supported. Effectively the same as a LTS release.

pmontra 3y ago

The ORM is OK as long as you refrain from using any inheritance. If you do, the database becomes a mess quickly and only that very Django app will be able to read and write to it (including manage.py shell). Anything else, other apps in any language or a SQL client, will be lost in a sea of tables and joins. I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. The database is a nightmare. The other one was developed thinking table by table and creating models that mimic the tables we want to have. That's a database we can also deal with from other apps and tools.

dd82 3y ago
tbh, any OOP paradigms used with db tables will end up in a clusterf*ck.
NoGravitas 3y ago
I've found inheritance to be a problem with pretty much any ORM I've used extensively (Django, Hibernate, NHibernate, Entity Framework). It helps to design your OOP model with that in mind; having no more than one level of inheritance, and using inheritance only to supplement a set of common records seem to be good enough rules of thumb.