6 ms·

If you don’t mind, I have some questions as I would like to learn more. Are you aware of a large models.py for reference and learning purposes? Is it expected t

If you don’t mind, I have some questions as I would like to learn more. Are you aware of a large models.py for reference and learning purposes? Is it expected to define the schema of all my models in a single place but none of the logic? Also, don’t you run into scenarios in Django where the automatic migration is not enough and you need to provide custom commands? In such cases, how do you provide them? And can you have scenarios where you have two models pointing to the same table, but perhaps to a subset of fields (this is specially useful in read-only cases)? How is that handled? Thank you :)

theptip 4y ago
> Also, don’t you run into scenarios in Django where the automatic migration is not enough and you need to provide custom commands? In such cases, how do you provide them? Data migrations are the obvious case where you need to write migration code manually. It comes up in schema migrations too on big projects. It’s easy to modify the auto-generated migration; it’s just Python that gets run by the migration tool: https://docs.djangoproject.com/en/4.1/topics/migrations/#data-migrations https://docs.djangoproject.com/en/4.1/topics/migrations/#dat...
traverseda 4y ago
>Are you aware of a large models.py for reference and learning purposes? Is it expected to define the schema of all my models in a single place but none of the logic? Django models are normal python classes. Depends on exactly the logic you're dealing with, but generally you can make logic be a method on that class. Try to avoid logic that spans multiple tables in general, and if you have logic that does span multiple tables you probably want it to be a function and not a model method. There are also signals that get sent on different things like model delete/create/etc, but they're to be used even more sparingly. Logic for querying data should probably go wherever you're going to use it and you should just pass the model objects directly to your views. To start don't worry about optimizing queries or the n+1 problem, but as you get more experience you can use `prefetch_related` in order to avoid the n+1 problem. >Also, don’t you run into scenarios in Django where the automatic migration is not enough and you need to provide custom commands? In such cases, how do you provide them? You shouldn't generally need to. That said django's migration system is very powerful and you can hand-write a migration if you need to. >And can you have scenarios where you have two models pointing to the same table, but perhaps to a subset of fields (this is specially useful in read-only cases)? How is that handled? I mean you can using proxy models but that's not really a thing with django. Models are for developers and generally developers have all the permissions any way, so the solution to making a model read only is to just not write to it. If you want to present a read-only model to an end user you can reference it in a view of make a read-only serializer with django-rest-framework. It's python, not java, there's no such thing as private/protected members just convention to put an "_" in front of things other developers probably shouldn't be messing around with.
- theptip 4y ago
  > I mean you can using proxy models but that's not really a thing with django. I think this is over-opinionated. You can use Proxy models, and this is a thing in Django. It’s not “Django 101” sure, but it’s not discouraged. One reason you might want proxy models is if you want to only fetch certain columns for a specific type of usage. Another common use for proxy models is as a hack to get multiple Django Admin pages for the same model (again, perhaps pulling different fields or offering different views).
- josevalim 4y ago
  Thanks for the insights, I appreciate it! I will take some time to go through the docs and learn more. One last question for now (I hope): after the migrations are auto-generated, do you check them into version control? > Models are for developers and generally developers have all the permissions any way To clarify, the reason why you would want to have read-only models is rather in complex data model cases or for performance reasons. For example, if you have a large model with 50 fields, defining a subset with 10 fields can be beneficial to performance in several queries. Other than that, I agree with you.
  - neillyons 4y ago
    You can use `managed = False` and `db_table` to have another model pointing to the same table. `managed = False` will stop Django automatically creating schema migrations. eg. ``` class ReadOnlyUser(models.Model): email = models.CharField(max_length=255) class Meta: db_table = "users" managed = False ```
  - POiNTx 4y ago
    Just wanted to say thank you for all the great work you've been doing. I'm a recent Elixir/Phoenix convert coming from a couple of years of full time Django and it makes me so happy to see you being interested in the way Django handles models. Imo it's one of the last things I'm struggling leaving behind (together with its tight integration of the Django admin, which you get for free). I haven't looked close into Ash but to me it seems their approach is interesting and offers a solution, not the way Django does it but it is a solution, although a bit hard to wrap your head around at first. Django models are more simple and straightforward.
ralmidani 4y ago
Hi José, thanks for joining the discussion! The sibling to this post (by “traverseda”) is more informed and informative than I could hope to write. I will add that Django has Manager classes that have default behavior included for interacting with the query API, and they can be customized to your needs. You can even have multiple managers for a given model. https://docs.djangoproject.com/en/4.1/topics/db/managers/ https://docs.djangoproject.com/en/4.1/topics/db/managers/ It’s been a few years since I used Django, but I remember its model layer fondly, and still follow the framework’s release processes. One of the areas where Django lags is being fully async (Python imposed a lot of limitations on async operations for most of its life). The upcoming 4.2 release of Django is laying the groundwork for async DB operations.
pg_1234 4y ago
I don't think this is something that will come down to technical merits. Unfortunately it is a popularity contest, where entrenched network effects are working against Elixir. As a Python programmer, I truly believe Elixir/Phoenix is the best stack out there from a technical perspective. However the incredible breadth of libs and resources ... and most importantly the mind share (both available devs, but more importantly available jobs for seniors who commit to Elixir) means that it is still just not a competitive choice. Almost all commercial software dev is not about technical excellence, but rather about applying the available tech to a particular business domain. And there Python (and .Net, Java, PHP, Ruby ... even Go) are so far ahead that sadly Elixir doesn't look like it will make it. I don't know that anything can be done about this. For all that I think Elixir is better, I, like most devs, am not about to sacrifice (or even impair) my career for the cause. Personal remuneration wins out.
- Alacart 4y ago
  That does seem like the same arguments that are made prior to just about anything becoming mainstream though. I'm not saying it means nothing that python has so much mindshare, but the same could have been said to pythons predecessors as well. You're right about commercialization not being about technical excellence, in the short term. In the medium and long term, it's the advantages of recent technical excellence that drives a lot of commercialization.
  - pg_1234 4y ago
    It's also the same arguments that are made prior to things falling by the wayside. Not that I think Elixir will ever fall away, just that it won't go fully mainstream.
    - Alacart 4y ago
      Very true, maybe it's not a strong predictor either way.

theptip 4y ago

> Also, don’t you run into scenarios in Django where the automatic migration is not enough and you need to provide custom commands? In such cases, how do you provide them? Data migrations are the obvious case where you need to write migration code manually. It comes up in schema migrations too on big projects. It’s easy to modify the auto-generated migration; it’s just Python that gets run by the migration tool: https://docs.djangoproject.com/en/4.1/topics/migrations/#data-migrations https://docs.djangoproject.com/en/4.1/topics/migrations/#dat...

traverseda 4y ago

>Are you aware of a large models.py for reference and learning purposes? Is it expected to define the schema of all my models in a single place but none of the logic? Django models are normal python classes. Depends on exactly the logic you're dealing with, but generally you can make logic be a method on that class. Try to avoid logic that spans multiple tables in general, and if you have logic that does span multiple tables you probably want it to be a function and not a model method. There are also signals that get sent on different things like model delete/create/etc, but they're to be used even more sparingly. Logic for querying data should probably go wherever you're going to use it and you should just pass the model objects directly to your views. To start don't worry about optimizing queries or the n+1 problem, but as you get more experience you can use `prefetch_related` in order to avoid the n+1 problem. >Also, don’t you run into scenarios in Django where the automatic migration is not enough and you need to provide custom commands? In such cases, how do you provide them? You shouldn't generally need to. That said django's migration system is very powerful and you can hand-write a migration if you need to. >And can you have scenarios where you have two models pointing to the same table, but perhaps to a subset of fields (this is specially useful in read-only cases)? How is that handled? I mean you can using proxy models but that's not really a thing with django. Models are for developers and generally developers have all the permissions any way, so the solution to making a model read only is to just not write to it. If you want to present a read-only model to an end user you can reference it in a view of make a read-only serializer with django-rest-framework. It's python, not java, there's no such thing as private/protected members just convention to put an "_" in front of things other developers probably shouldn't be messing around with.

theptip 4y ago
> I mean you can using proxy models but that's not really a thing with django. I think this is over-opinionated. You can use Proxy models, and this is a thing in Django. It’s not “Django 101” sure, but it’s not discouraged. One reason you might want proxy models is if you want to only fetch certain columns for a specific type of usage. Another common use for proxy models is as a hack to get multiple Django Admin pages for the same model (again, perhaps pulling different fields or offering different views).
josevalim 4y ago
Thanks for the insights, I appreciate it! I will take some time to go through the docs and learn more. One last question for now (I hope): after the migrations are auto-generated, do you check them into version control? > Models are for developers and generally developers have all the permissions any way To clarify, the reason why you would want to have read-only models is rather in complex data model cases or for performance reasons. For example, if you have a large model with 50 fields, defining a subset with 10 fields can be beneficial to performance in several queries. Other than that, I agree with you.
- neillyons 4y ago
  You can use `managed = False` and `db_table` to have another model pointing to the same table. `managed = False` will stop Django automatically creating schema migrations. eg. ``` class ReadOnlyUser(models.Model): email = models.CharField(max_length=255) class Meta: db_table = "users" managed = False ```
- POiNTx 4y ago
  Just wanted to say thank you for all the great work you've been doing. I'm a recent Elixir/Phoenix convert coming from a couple of years of full time Django and it makes me so happy to see you being interested in the way Django handles models. Imo it's one of the last things I'm struggling leaving behind (together with its tight integration of the Django admin, which you get for free). I haven't looked close into Ash but to me it seems their approach is interesting and offers a solution, not the way Django does it but it is a solution, although a bit hard to wrap your head around at first. Django models are more simple and straightforward.

ralmidani 4y ago

Hi José, thanks for joining the discussion! The sibling to this post (by “traverseda”) is more informed and informative than I could hope to write. I will add that Django has Manager classes that have default behavior included for interacting with the query API, and they can be customized to your needs. You can even have multiple managers for a given model. https://docs.djangoproject.com/en/4.1/topics/db/managers/ https://docs.djangoproject.com/en/4.1/topics/db/managers/ It’s been a few years since I used Django, but I remember its model layer fondly, and still follow the framework’s release processes. One of the areas where Django lags is being fully async (Python imposed a lot of limitations on async operations for most of its life). The upcoming 4.2 release of Django is laying the groundwork for async DB operations.

pg_1234 4y ago

I don't think this is something that will come down to technical merits. Unfortunately it is a popularity contest, where entrenched network effects are working against Elixir. As a Python programmer, I truly believe Elixir/Phoenix is the best stack out there from a technical perspective. However the incredible breadth of libs and resources ... and most importantly the mind share (both available devs, but more importantly available jobs for seniors who commit to Elixir) means that it is still just not a competitive choice. Almost all commercial software dev is not about technical excellence, but rather about applying the available tech to a particular business domain. And there Python (and .Net, Java, PHP, Ruby ... even Go) are so far ahead that sadly Elixir doesn't look like it will make it. I don't know that anything can be done about this. For all that I think Elixir is better, I, like most devs, am not about to sacrifice (or even impair) my career for the cause. Personal remuneration wins out.

Alacart 4y ago
That does seem like the same arguments that are made prior to just about anything becoming mainstream though. I'm not saying it means nothing that python has so much mindshare, but the same could have been said to pythons predecessors as well. You're right about commercialization not being about technical excellence, in the short term. In the medium and long term, it's the advantages of recent technical excellence that drives a lot of commercialization.
- pg_1234 4y ago
  It's also the same arguments that are made prior to things falling by the wayside. Not that I think Elixir will ever fall away, just that it won't go fully mainstream.
  - Alacart 4y ago
    Very true, maybe it's not a strong predictor either way.