Why is ModelAdmin to Model a 1-1 relationship?
In our application, we have a Model that has a boolean field named "deleted". When the delete() method is called, we set the deleted field to 1 and then save the model. We would like to create an admin site where we can manage the deleted and non deleted instances separately. We could accomplish our goal by defining a queryset function for the ModelAdmin that restricts the instances returned to deleted=0. However, AFAIK this would eliminate the ability to undelete instances via the admin. Another option is to allow all instances to be shown and include delete as a value in the list_filter list for the admin but that clutters up our UI and requires an extra click. It would be nice if we could specify that the default admin view for this model has a list_filter of deleted=0 but I don't think this is currently possible. I think a good solution would be to create two ModelAdmins. One to display active instances and one to display deleted instances. With this approach we could define a queryset function for each ModelAdmin and when an instance is deleted it would automatically move to the correct ModelAdmin. This is explicitly denied in django/contrib/admin/ sites.py. Simply removing this check does not solve our problem but overwrites the first ModelAdmin for the model with the second via the dictionary "_registered" in the AdminSite class. From my brief dive into the admin site, there doesn't appear to be a real need for a one to one relationship between ModelAdmins and Models. If you allowed ModelAdmins to specify their own name I think it would be possible to have more than one ModelAdmin for a Model. I am not a Django expert but I don't see a reason that this scenario should be excluded. Can anyone recommend a way to accomplish either of the approaches I outlined above or propose a new approach that does not violate the AdminSite rules? Also, if anyone knows why the ModelAdmin needs to have a one to one relationship with Model please let me know. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django Test Corrupted Test Data
As I understand it, the database should be reset between each test. To me this means that unless the variable being examined is an attribute of self, the tests shouldn't affect each other. Could it be possible that there is a sqllite subtly that delays the reset of the table count and it affects the outcome of the test in this instance? On Aug 19, 3:43 pm, bik...@gmail.com wrote: > Could it be that the tests affect each other (when ran in a series)? > > Sent from my BlackBerry® from Vodafone > > -Original Message- > From: dm03514 > > Sender: django-users@googlegroups.com > Date: Fri, 19 Aug 2011 12:13:24 > To: Django users > Reply-To: django-users@googlegroups.com > Subject: Django Test Corrupted Test Data > > I have a test class that subclasses django.test.TestCase which has > about 5 different tests in it. When I run my full test suite (using > nose, and specifying sqlite as backend) there are a series of > failures. When I go to debug the tests, running them individually, > they pass fine. > > http://stackoverflow.com/questions/7126172/django-testrunner-incorrec... > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
