Difficulty setting dynamic 'db_table' in Meta

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Difficulty setting dynamic 'db_table' in Meta

Brock Hallenbeck
I am trying to modify django's default table naming scheme to better suit my needs and am having some difficulty.

In order to accomplish this I need access to the 'app_label' and 'model_name' attributes. However due to python's scoping, I am unable to do so in your standard Meta subclass.

I have successfully implemented a custom metaclass, that overrides __new__ in order to set the 'db_table' attribtue to what I want, however upon running makemigrations, this custom behavior is seemingly ignored.

This stack overflow question illustrates the problem.

Is there some magic that I am not aware of going on inside makemigrations?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Difficulty setting dynamic 'db_table' in Meta

Adam Johnson-2
Hi,

The SO post shows you (?) testing on Django 1.10, have you tried with the latest 2.2?

You could also try implementing this with just a class decorator which is much more likely to work, although it’s not inheritable. 

You could also enforce with a a custom system check for manual declaration of db_table. It could iterate over the models in your project’s apps and return one check Error for each model with a db_table that doesn’t match the desired naming scheme.

Thanks,

Adam

On Wed, 26 Jun 2019 at 15:50, Brock Hallenbeck <[hidden email]> wrote:
I am trying to modify django's default table naming scheme to better suit my needs and am having some difficulty.

In order to accomplish this I need access to the 'app_label' and 'model_name' attributes. However due to python's scoping, I am unable to do so in your standard Meta subclass.

I have successfully implemented a custom metaclass, that overrides __new__ in order to set the 'db_table' attribtue to what I want, however upon running makemigrations, this custom behavior is seemingly ignored.

This stack overflow question illustrates the problem.

Is there some magic that I am not aware of going on inside makemigrations?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2p9y9xEmZ2iAAfwDfLowmOqVcFnZf5cX8oBcTkvQqS3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Difficulty setting dynamic 'db_table' in Meta

Brock Hallenbeck
Sorry for the confusion. That post is not actually me, just an identical situation. I am in fact on 2.2. It's just frustrating because I can raise an arbitrary exception in my metaclass and makemigrations will fail because of it, so I know the code is being run. It just seems to be inexplicably ignored. 

I will look into the decorator, although I am sad i'll be losing inheritance.

On Wednesday, June 26, 2019 at 12:01:31 PM UTC-4, Adam Johnson wrote:
Hi,

The SO post shows you (?) testing on Django 1.10, have you tried with the latest 2.2?

You could also try implementing this with just a class decorator which is much more likely to work, although it’s not inheritable. 

You could also enforce with a a custom system check for manual declaration of db_table. It could iterate over the models in your project’s apps and return one check Error for each model with a db_table that doesn’t match the desired naming scheme.

Thanks,

Adam

On Wed, 26 Jun 2019 at 15:50, Brock Hallenbeck <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="RUI-pJvABwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">bhallen...@...> wrote:
I am trying to modify django's default table naming scheme to better suit my needs and am having some difficulty.

In order to accomplish this I need access to the 'app_label' and 'model_name' attributes. However due to python's scoping, I am unable to do so in your standard Meta subclass.

I have successfully implemented a custom metaclass, that overrides __new__ in order to set the 'db_table' attribtue to what I want, however upon running makemigrations, this custom behavior is seemingly ignored.

<a href="https://stackoverflow.com/questions/51115249/django-migrations-ignoring-db-table-when-set-using-metaclass" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fquestions%2F51115249%2Fdjango-migrations-ignoring-db-table-when-set-using-metaclass\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1wulvSTnPU2y7fSvVLmDqxnFFeg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fquestions%2F51115249%2Fdjango-migrations-ignoring-db-table-when-set-using-metaclass\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1wulvSTnPU2y7fSvVLmDqxnFFeg&#39;;return true;">This stack overflow question illustrates the problem.

Is there some magic that I am not aware of going on inside makemigrations?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="RUI-pJvABwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="RUI-pJvABwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e0061fa8-8f09-4ba2-ba67-34b55b0e7d74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Difficulty setting dynamic 'db_table' in Meta

Adam Johnson-2
So it looks to me like migrations feeds off of models.original_attrs: https://github.com/django/django/blob/master/django/db/models/options.py#L160 / https://github.com/django/django/blob/master/django/db/migrations/state.py#L453

This is set at contribute_to_class time in the Meta. The __new__ method in the SO post mutates _meta but not its original_attrs. I think if it was changed to mutate original_attrs as well, it would work.


On Wed, 26 Jun 2019 at 17:41, Brock Hallenbeck <[hidden email]> wrote:
Sorry for the confusion. That post is not actually me, just an identical situation. I am in fact on 2.2. It's just frustrating because I can raise an arbitrary exception in my metaclass and makemigrations will fail because of it, so I know the code is being run. It just seems to be inexplicably ignored. 

I will look into the decorator, although I am sad i'll be losing inheritance.

On Wednesday, June 26, 2019 at 12:01:31 PM UTC-4, Adam Johnson wrote:
Hi,

The SO post shows you (?) testing on Django 1.10, have you tried with the latest 2.2?

You could also try implementing this with just a class decorator which is much more likely to work, although it’s not inheritable. 

You could also enforce with a a custom system check for manual declaration of db_table. It could iterate over the models in your project’s apps and return one check Error for each model with a db_table that doesn’t match the desired naming scheme.

Thanks,

Adam

On Wed, 26 Jun 2019 at 15:50, Brock Hallenbeck <[hidden email]> wrote:
I am trying to modify django's default table naming scheme to better suit my needs and am having some difficulty.

In order to accomplish this I need access to the 'app_label' and 'model_name' attributes. However due to python's scoping, I am unable to do so in your standard Meta subclass.

I have successfully implemented a custom metaclass, that overrides __new__ in order to set the 'db_table' attribtue to what I want, however upon running makemigrations, this custom behavior is seemingly ignored.

This stack overflow question illustrates the problem.

Is there some magic that I am not aware of going on inside makemigrations?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e0061fa8-8f09-4ba2-ba67-34b55b0e7d74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0tTOtAVBkzK25hZ5WCm4T9EFXvxQ6z6jR%3D%3DdyM-ZA%2BRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.