> > The imported connection is never used in the method, > > Look closer - it is used, right at the end of contribute_to_class. The > connection is used to get the operations module for the backend, which > is then used to determine if the generated database table name needs > to be truncated.
Oops. I thought that was part of the #6148 patch. :) > Sounds like a bug in the patch to me. As I said earlier, the options > class doesn't have any knowledge about the database that is being used > for a specific operation, so it can't enforce per-database > restrictions. In the case of db_table truncation, I suspect the right > approach here is to store db_table as an untruncated string, and then > truncate it at time of use inside specific backends or in queries. I > suspect analogous changes will be required for #6148. > > This should also be logged as a bug; the truncation behavior that is > currently implemented is definitely wrong. Thanks for the information. I will log a bug regarding the db_table truncation and reference this thread in it. Hopefully I will be able to describe the problem adequately. I will also raise the issue on ticket #6148. I have a feeling the code contributed to this method by the patch for #6148 will just need to be removed. The side effect being a lot of dependent code would need to change. The patch adds what appears to be a convenience member called qualified_name that is constructed by using another new member db_schema and db_table. It calls connections.ops.prep_db_table(self.db_schema, self.db_table) which combines them in a db specific manner and qualified_name is set from the resulting string. I am not sure where else this member could be initialized where it would have access to the correct connection. Sounds more likely that it must just be removed and constructed every were a table name is needed. It occurred to me to turn qualified_name into a "lazy loaded" member using a getter and a property(…) on Options, but as you point out it still needs a connection and in addition it appears the correct way to get a connection is to "ask" a router what connection to use for a given Model instance. Since Options is part of a Model instance's _meta instance I am not sure how I would call router.db_for_read() from a Options getter method. Peter Long -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
