I'm was confirming ticket #2493 (Error resetting app with self- referencing ForeignKey) this evening and as I began to poke into it it appears that the fix is what mtredinnick recommended, to use introspection to get the foreign key relation name when constructing the alter table drop statement for the foreign key.
The issue of the ticket is not really the reason for this discussion, but rather the larger issue of understanding the design goals of the sqlreset / reset commands. To me the best approach when constructing the drop statements is to use introspection solely to figure out what needs to be dropped. This includes not only for the foreign key relationships but also for the tables themselves. With the current design the table and foreign key information is pulled together from the model information itself. The problem with that is that if someone manually changes the name of an foreign key constraint or removes the constraint entirely then the constructed information will differ from what is in the database and therefore the drop statements will fail. In addition, somewhat related to this, if a user attempts to change the name of a model and then does a reset it will fail, because the constraint names and the table name itself will no longer match up to what is being constructed by the sql_delete function. If introspection is used entirely for the constructing the drop statements then it would solve all of the above issues. Thoughts? Michael Trier blog.michaeltrier.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
