That sounds more like an exact use case for model inheritance. You would define a single model that matches the columns in both tables. You can define that model as abstract, then have the two real models (one for each table) inherit from that abstract model. In the definition for the child models, you would specify the DB table names to match your two tables in the existing schema.
https://docs.djangoproject.com/en/1.7/ref/models/options/#db-table That way, you only maintain a single (abstract) model definition, even though multiple models use it (each with a separate DB table). You may also need to mark the real models as unmanaged by the ORM if you're doing funny things directly in the DB, and you will be managing the table schema directly for those tables. https://docs.djangoproject.com/en/1.7/ref/models/options/#managed I'm assuming you have already determined the logic deciding which model each user uses. At that point, assuming that all other functionality remains the same (calls/processing the data, regardless of table), the calls to those models can be generalized by a simple utility function that returns a class instance of the necessary model. def get_right_model(user): # logic to pick ModelA or ModelB based on user return ModelA Then later, maybe in a view: selected_model = get_right_model(self.request.user) all_data = selected_model.objects.all() #all_data should now contain the results of the query against the right model/table in the DB Trying to flip between tables in the ORM by tweaking the innards probably is going to lead to excessive complication. -James We have two tables that — for legal reasons — are not allowed to be combined. The data is so similar that we are using PostgreSQL table inheritance <http://www.postgresql.org/docs/9.4/static/ddl-inherit.html>, but we can’t return the information in the same page. Originally, we only had one table with a column specifying which data set to use, but or lawyers put an end to that. So we have two tables tables with the exact same columns: product_foo and product_bar. We also have two models that use model inheritance so that they have the exact same fields: ProductFoo and ProductBar. The decision to choose which table to use is handled based on user settings. We would like to go back to just having the one Product model, and have its table name switch as necessary. Is there a way to do that? Peter of the Norse rahmc...@radio1190.org -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0A706025-5A66-47E3-B524-222E1780ADA4%40radio1190.org <https://groups.google.com/d/msgid/django-users/0A706025-5A66-47E3-B524-222E1780ADA4%40radio1190.org?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXKkQ2Lpq1F-KBpHkndLWxi_8dCVamXJ-G7Bji3QZWcmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
