On 9/12/06, Gary Doades <[EMAIL PROTECTED]> wrote: > You mean every TYPE of object surely. I'd like to see it list 10 million > records :)
Nope. It lists the objects. The utility of this will vary widely with your use case -- when you have, say, one object which is related to ten million other objects, then it's going to suck. We could do with a better way to handle that, maybe something like what we do with raw_id_admin for creating the relations between objects in the first place (the default behavior in the admin is to show an HTML 'SELECT' element populated with the entire list of possible choices for an FK, but the 'raw_id_admin' option switches it to a numeric input of an object ID with some JavaScript to help you browse and select the right one). > Even so, if the user selects YES, I'd still be pretty upset. Personally I like > the database to have the last word in this case for what can be deleted and > what can't. There are a couple lines you can comment out which I'm pretty sure will prevent Django manually cascading the delete (see gabor's post below for where to look), at which point if you've specified ON DELETE behavior at the database level that will kick in. But for the moment you'll also need to add your own checks at the Django level to catch the exception that will be raised when you try to delete something and the DB won't let you. > I understand this, but I'm not sure why Django has to be broken to accommodate > these databases. As I said, if the database cannot support proper foreign > keys, then fall back to the sledge hammer cascade delete approach, otherwise > do the right, and simpler thing. That's an option. Personally, I'd rather see us emulate the standard ON DELET/ON UPDATE options for DBs which don't support them, so that this functionality would become more portable. > And SQLServer and Sybase (Enterprise and SQLAnywhere) and Oracle and ... Should have said "Postgres is the only DB *officially supported by Django* which supports..." > I know that Django doesn't support them all (yet), but people do use them a > bit. And there are experimental Oracle and SQL Server backends that we'd love to get some help testing; I'm in the unfortunate (well, not really so unfortunate for me...) position of working in an open-source-only shop, and I don't have the spare cash lying around to set up personal testbeds for those DBs. So we need someone who does have access to a suitable testing setup to help out with those. > I'm not yet familiar enough with the Django code to offer a true solution > (simple or not), but I'm quite willing to debate the issues and possible > solutions. Given that it pertains more to future development of Django, this might be better hashed out on the django-developers list (I'm pretty sure there are people who help us hack on Django who don't subscribe to both lists, and django-developers is probably the more appropriate forum anyway). -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
