Re: considering django for The Freesound Project, some (de)constructive critisism
On Jan 21, 4:22 pm, Bram - Smartelectronix <[EMAIL PROTECTED]> wrote: > 2. file uploads are the most vital part of freesound. While I have used > tramline successfully with splice, it still feels like a relatively ugly > solution to me (especially as you need to patch mod_python in order for > it to work). As far as I know streaming file uploads have been on the > todo for more than a year. Some load balancers (include the ability to handle streaming file uploads for you. Essentially, the load balancer can intercept the file upload and write it to disk as it slowly comes in, then splurge it all through to the application running behind it at once when the whole file is available to the load balancer. I'm pretty sure Perlbal has this ability. Would this solve your file upload problem, or is there something else that I'm missing? Cheers, Simon Willison --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: considering django for The Freesound Project, some (de)constructive critisism
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.
>
> 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.
>
> 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()
>
> 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
-~--~~~~--~~--~--~---
Re: considering django for The Freesound Project, some (de)constructive critisism
> 2. file uploads are the most vital part of freesound. While I have used > tramline successfully with splice, it still feels like a relatively ugly > solution to me (especially as you need to patch mod_python in order for > it to work). As far as I know streaming file uploads have been on the > todo for more than a year. This is not about streaming, but maybe it helps someone : I had trouble with FileField, too. But then I realized, that I don't need it. What does it offer? Only the filename is stored in the database. If you want to store N files for an object, you need to create a new table/model. I use this: Every object has a corresponding directory in the filesystem: .../files/OBJECT-ID/ I store the files there. The filename get's quoted with django.utils.http.urlquote() this way the filenames contain only ascii characters. Thomas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: considering django for The Freesound Project, some (de)constructive critisism
James Bennett wrote on 01/21/08 18:26: > On Jan 21, 2008 10:22 AM, Bram - Smartelectronix > <[EMAIL PROTECTED]> wrote: [...] > >> 3. finegrained permissions. "I only want my friends to be able to edit >> my tags." Again people seem to be working on this, but nothing seems to >> be making it into trunk. Does anyone have a good soliution for this >> particular problem, or is it still really a matter of "roll your own"? > > 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. Christian Joergensen has written a nice article on his blog which among other things also shows a possible solution for this [1] [1] http://www.technobabble.dk/2008/jan/06/filtering-foreign-key-choices-newforms-admin/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: considering django for The Freesound Project, some (de)constructive critisism
On Jan 21, 2008 10:22 AM, Bram - Smartelectronix <[EMAIL PROTECTED]> wrote: > 1. huge numbers of users make the admin almost unusable. Almost any > objects is related to a user (or two). Having to load 500K users in a > form makes for ultra big and slow web pages. Is there a fix for this > somewhere in the future? 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? ;) > 2. file uploads are the most vital part of freesound. While I have used > tramline successfully with splice, it still feels like a relatively ugly > solution to me (especially as you need to patch mod_python in order for > it to work). As far as I know streaming file uploads have been on the > todo for more than a year. 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. > 3. finegrained permissions. "I only want my friends to be able to edit > my tags." Again people seem to be working on this, but nothing seems to > be making it into trunk. Does anyone have a good soliution for this > particular problem, or is it still really a matter of "roll your own"? 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. > 4. profiles and get_profile() in the django User. In splice we noticed > that having to use get_profile() creates a big overhead in queries... > This seemed to fix this problem: > http://www.amitu.com/blog/2007/july/django-extending-user-model/ > but seems quite "hacky" as well. Big overhead how? get_profile() hangs on to its result so it won't need to query again. 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"?). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
