> 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.
>
Great, this was very helpful.
> > 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?
Yes, of course you are right. I still hadn't fully grocked that delete
() never get called in this case. I get that now.
> 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.
>
Well, that seems a little heavy handed. I mean, when trying to create
db driven web app, I think it is important to allow the users to
delete the objects and not have bad side effects. That said, I
understand that django is a developer's tool and there is always a
workaround that a developer can come up with. I found one that works
fine for my particular app.
> 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.
yup, agreed it is a hard problem. I appreciate that you guys no doubt
have your hands full and am absolutely fine with dealing with it as
is. Thanks for your pointers, they were very helpful and I've dug my
self out of my hole.
Margie
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
