Karen Tracey wrote:
> On 10/31/07, *George Vilches* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Or (I just saw your follow-up e-mail), is all of this a moot point since
> something like this is going to be made totally invalid in the future?
>
>
> That's it. Targeting a non-unique column in a ForeignKey field is
> invalid. It's invalid now, and will continue to be invalid. The
> difference is that it's not caught and flagged as an error now, and will
> be when queryset-refactor gets merged into trunk.
>
> If you can whittle down your real problem to an example that does not
> include this kind of invalid relationship (you said you are actually
> using OneToOne fields?) maybe we could make some progress on
> understanding/solving the real issue you are facing.
Here's an example that's a lot closer to home:
class Person(models.Model):
name = models.CharField(max_length=100)
status = models.IntegerField()
class PersonInfo(models.Model):
person = models.OneToOneField(Person)
phone = models.CharField(max_length=10)
>>> from qs.models import *
>>> Person.objects.create(name='user1', status=1)
<Person: Person object>
>>> PersonInfo.objects.create(person_id=1, phone='111')
<PersonInfo: PersonInfo object>
>>> PersonInfo.objects.create(person_id=99, phone='222')
<PersonInfo: PersonInfo object>
Yes, I know. At this point we've added a PersonInfo that doesn't map to
an existing person (id=99).
If at this point you're saying, "well that's stupid", I would ask you to
point out where it says that a OneToOneField has any sort of forced
referential integrity across the relationship (it most definitely is not
generating constraints like the unique ForeignKey does). I don't think
it is a requirement, and would ask that you take the rest of this
example in that spirit.
>>> PersonInfo.objects.count()
2L
>>> PersonInfo.objects.filter(person__id__gte=-1).count()
2L
>>> PersonInfo.objects.filter(person__status__gte=-1).count()
1L
So the filter has to be on a non-related field in order to get the query
to force the INNER JOIN and not optimize the result out.
More importantly, I'm getting different counts, and the reasoning seems
to be based on an internal optimization. That seems like a bug to me,
I've made an effort to get a fake filter on the other table, and am
still denied the accurate count.
What can I do to get the JOIN without having to also generate a (very
slow when data sets are large) useless WHERE clause?
---
Someone might suggest that I do the selection from the POV of Person:
Person.objects.filter(personinfo__...). This is no good because I need
to use the data from both Person and PersonInfo (I didn't put the
select_related() in here for clarity's sake), and OneToOneFields don't
work in the opposite direction, so I'd get a bunch of extra queries, one
for each instance of Person returned (to get the PersonInfo bits). The
intention here is for reporting, and that returns a lot of rows, so I
need to select on the relationship in the direction that caches the most
data.
If OneToOneFields worked in both directions from the point of view of
select_related(), which seems like a reasonable assumption, then pretty
much this entire e-mail would not be a problem. Malcolm, is this
something that might be happening in qs-rf, having a OneToOneField that
will follow in both directions? We have a setup that looks like this:
User is the base class, and then Member, MemberInfo, MemberData, and
about 5 others all have OneToOneFields to User. We would *LOVE* to be
able to do User.select_related(depth=2) and get all those relations in a
single query. Right now, you can at most 2 tables/models worth of data
with a single query, and all the other model instances that are touched
result in an extra query. Yuck. :)
Thanks,
George
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
