Hello all,
James Bennett wrote:
> The fix has been in Django since the day it was publicly released:
> 'raw_id_admin=True'. You think World Online runs sites with tens of
> thousands of users and hundreds of thousands of stories without
> running into that? ;)
Ah... Those details one tends to skip over while reading the manual :)
>> 2. file uploads are the most vital part of freesound. <snip>
>
> This is one of those things that's taking a while because it's a
> genuinely hard problem. The ticket is there, it's under more or less
> constant work, so if it's important to you pitch in and help.
File uploads seem a very advanced field, looking at the patches. I feel
VERY incompetent in this field, so my help would hardly be useful.
Neither do I have a lot a of time to experiment, ... As you can
understand, this becomes a rather difficult problem.
>> 3. finegrained permissions. <snip>
>
> I keep meaning to write a blog entry on how easy it is to do this in
> newforms-admin; all the ugly hacks people have come up with to try to
> do this just go away.
This does look exactly like what I need... Looking at the tickets in
svn, newforms-admin looks to be very far from done... Can newforms-admin
be used as is?
Does it have the equivalent of BackwardsIncompatibleChanges ?
>> 4. profiles and get_profile() <snip>
>
> Big overhead how? get_profile() hangs on to its result so it won't
> need to query again.
As -most likely- all your objects refer to user and not profile one
always tends to go through user and query get_profile. For example, say
you have books and you want to list a list of 20 books, their authors
and their birthday:
{% for book in books %}
.... {{ book.author.get_profile.birthday }}
{% endfor %}
which will invariably trigger another query "from" the template for each
book you display, making it hard to control where exactly extra queries
will be "generated". Now you are going from one big and fast "join"
query to 20 smaller ones.
Were there some method of adding information to User, one could (more
easily) use of select_related to get the information in one big query
and do:
{% for book in books %}
{{ book.author.birthday }}
{% endfor %}
Which also LOOKS a lot cleaner.
> Also, the "hacky" method is dangerous when you have multiple sites (if
> Site A and Site B both want to add a field of the same name, whose
> field "wins"?).
That's true, but in 99.9% of the cases you would be involved in both the
code for siteA and siteB.
- bram
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
