On Sun, 2009-04-12 at 00:40 -0700, Margie wrote: [...] > Let's say that my Publisher and Book classes are in one app, and that > app doesn't know anything about the readers. Is there any simple way > to find all related object fields that point to book and clear them > out, without having to know their names
For a model such as Book, you could iterate through Book._meta.get_all_field_names(), call Book._meta.get_field_by_name() for each name and look at the "direct" component of the returned result to see which are the reverse relations. Those are then the things pointing to your model. There are docstrings on get_field_by_name() and get_all_field_names() in django/db/models/options.py that will help you out there. > ? > > One other thought - let me know if you see any issue with this. Let's > say I just never want my reader objects to get deleted based on > related object deletions. I think I can just define > > class Reader: > def delete(self): > pass > > Then delete will do nothing and if I really want to delete my reader I > can call some other method that I define that then calls super(Reader, > self).delete(). That will work for a direct call. Isn't there going to be some related object deletion cases that still won't be caught, though? Isn't this exactly the case that you were examining in the initial post? > The actual object that is my "reader" (the above example was used just > for simplicity) is really my UserProfile object. I would think that > this is a common problem Boy do I hate that phrase! For every possible programming problem, there is certainly a non-zero number of people who want some particular piece of behaviour. But there's pretty much no way to measure "common" unless you have a total userbase of, like, 17 people. At some point, everything is both common to some group and pretty much irrelevant to the majority. > - not wanting one's userProfiles to ever get > deleted. Ultimately, Python is a language for consenting adults. If you don't want the object to be deleted, don't call delete on things involving that object. It's understood that delete behaviour is something that has a few different options. Coming up with a save API for controlling those which doesn't leak SQL-juice all over the Python level code or make things horribly an untenably inefficient, has been something we've been wrestling with for quite a while. So far without really having a great solution that we're happy committing. This isn't for want of actual hard thinking on the problem by a number of people. For now, it's a matter of being careful and trusting your users to not do crazy stuff. It's not optimal, but it is survivable. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
