Hi Tomasz
Yes, i have followed a raw sql approach now im looking at my test data
to see which objects have multiple rows and cleaning that up.
Its a shame that '__in' has limited use under these scenarios:
directories = search_querySet.distinct()
addresses = Address.objects.filter(directory__in=directories)
addresses.values('directory__id', ..... *some other relevent fields*)
this certainly allows me to select the related sets of addresses for
each directory however i need to be able to relate each address object
back to its directory (by id would be great) trying to get the
directory 'id' packaged in the values() gives me an error saying
invalid field even though 'directory' is listed as a valid field.
If i could do that then i could iterate through each dictionary and
zip related items together based on their directory id's or something
nice like that.
"
Re those VIEWs, they are SELECTs with JOINs, which effectively
produce up to a few rows for single object (e.g. if you have person
with 3 phone numbers,
you're getting 3 rows), but it turns out to be much more efficient to
process/merge
that in Python code than to issue hundreds of SQL queries.
"
Yes this seems to be the best way, do you have any links where i can
see how various people have implemented this? Would be good to write a
'pythonic' solution
cheers
-sam
2010/1/4 Tomasz Zieliński <tomasz.zielin...@pyconsultant.eu>:
> On 31 Gru 2009, 01:56, Sam Walters <mr.sam...@gmail.com> wrote:
>
>> for s in search_querySet:
>> address_info = s.address_set.all() #.select_related(depth=2) -
>> yes i can/will put select related here but it really does not help
>> that much 20% tops
>> #address_info is usually 2-3 rows from an address table
>> for a in address_info:#.select_related(depth=2):
>> if a.addresstype.adrtype == 'Physical' and
>> a.addradmin.addr_enabled == True:
>> #further reduction in the number of rows which we need to
>> get values from.
>> related_phone=a.phone_set.all()
>> related_email=s.email_set.all()
>> #phones and emails are a small number of rows 2-3 tops
>>
>> It is these lines which produce the performance hit.
>> I cant see a way of using django's query language to avoid having to
>> descend into each of the 500 'directory' objects because of the
>> necessity to get all rows from the related tables in phones an emails
>> and to inspect the type of 'address' object.
>>
>
> I solved very similar problem by creating database VIEWs with data I
> needed,
> wrapping those VIEWs with unmanaged Django models and then using
> simple .filter(...)-s.
>
> Re those VIEWs, they are SELECTs with JOINs, which effectively
> produce up to a few rows for single object (e.g. if you have person
> with 3 phone numbers,
> you're getting 3 rows), but it turns out to be much more efficient to
> process/merge
> that in Python code than to issue hundreds of SQL queries.
>
> --
> Tomasz Zielinski
> http://pyconsultant.eu
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@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.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
