koenb wrote: > First things first: I would either define a separate Group object > here, or use a many2manyfield if you don't need to know the group > numbers.
The example was crafted because the actual models and data are part of a internal application that I am not allowed to publish the source of, and is more appropriately structured in the DB (no fake integers to demonstrate the problem). This example strictly demonstrates the problem we're seeing internally in the most minimal set we could devise. > Second thing: why use the assembly object if you want to count items ? > You are thinking to much in SQL instead of ORM. > If you say Assembly.objects.count(), I would think you want to count > assembly objects, which should yield 2 no matter what extra stuff you > pull in using select_related(). For the ORM side of things, > select_related just prepopulates some related data, no more, no less > (which is of no use in combination with count). > In that view, it would be better if the filter would automatically use > distinct here and also return 2, since you are still only counting > assembly objects. If you do the same using a many2manyfield, the > result is correct as far as I can tell. > If you want to count items, I would use > Item.objects.filter(whatever_filter).count(). Here is what I want to count: "All the quantity of items necessary to complete all the selected assemblies". That's not thinking in SQL, that's very much thinking about the objects at hand. I have Assemblies, and I need to know the total number of Items. That's a concept that can be thought about strictly from the objects. So, if I have two assemblies, and Assembly 1 connects to 2 items, and Assembly 2 connects to 3 items, I want the total result of 5 when I do a count() where I refer to the Items (select_related()). .select_related() does more than "prepopulates some related data". It actively changes the face of the total information pulled, especially when you are filtering on ForeignKey-based criteria. I can filter on something that's more than two relations away, and I would be changing the total face of the data that's being made available in the ORM. But all of this is besides the point, because one way or the other, Django is doing *something* wrong. Sometimes the .count() returns 6, and sometimes it returns 2 in the provided examples. From your point of view, it should always return 2. From my point of view, it should return 6 whenever .select_related() occurs. Either way, neither of our behaviors are occurring, and we probably need someone more intimate with the Django internals to verify if this is expected behavior. Do you see how my needs still fit within the concept of the ORM? Also, do you see how there's likely still a bug here of some sort? I'm as much interested as isolating the exact source of the bug as I am with getting the proper behavior defined for this activity. :) 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 -~----------~----~----~----~------~----~------~--~---
