On Thu, 2009-04-09 at 14:31 -0700, Adys wrote: > http://groups.google.com/group/django-developers/browse_thread/thread/87aae5cbd60bb904/505f3bd962711db7?hl=en > > You wanted an use case, someone else just provided you with it.
No they didn't. There's still an unanswered request in that thread to provide a legitimate use case. > "Why do you care so much about the index being there, anyway? It > should only > affect you badly under quite extreme circumstances." I'll go even further: the index won't affect you. Only the absence of the index will affect performance, since it will make using the relation require a linear scan for results, which will be *terrible*. Indexes are a good thing. They are one of things that make relational databases run. > > Yep. Point is giving the user freedom of choice. Sensible defaults, > "discouraging but not preventing", the python way. There's nothing about "the Python way" in this discussion. As best I (and other people) can work out, it's about you wanting a relation field at the database level that doesn't enforce the constraint or perform quickly. If you want that, you can freely use Python to implement your own not-really-a-proper-database-relation field. That's the Python way: you have the freedom to implement it and Django isn't stopping you from doing that (in fact, we've added lots of support for helping with custom fields). > As I explained in > the mail I just linked, I do not know all the use cases for this, I > just know mine: working with imported, corrupt data which needs to > stay intact. As crazy as it sounds, it's my job to make sure this is > what happens on my app. > I'm sure this situation isn't common. I'm also sure you're thinking > there are other/better ways to achieve that result. This still is a > valid use case. No, it's really not. Using related fields in a relation database requires consistent data. You have a case where related fields are not appropriate. That's a valid use-case for not using related fields, but instead just using something like an IntegerField, perhaps via a subclass with some extra methods to allow you to access the possibly related objects. > I'll be happy to help with a proper patch, or to stop pushing for one > if it gets refused. I can't see it happening at all. You've certainly spent a lot of time explaining your situation, which is good, as it helps ensure we really are all understanding the various sides. But your use-case isn't about using related fields -- it shows that you should be expressing your modelling requirements a different way at the Django level. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
