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?

[Adam Johnson]

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

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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

[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 <bhallen...@gmail.com> 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 django-d...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
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

[Adam Johnson]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
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