New project - django-requests
I started a new project on google code, django-requests[1], and i'm looking for opinions, suggestions, help.. The project goal is make a simple and generic way to moderate requests made by users to add, edit or remove objects. Thanks [1] - http://code.google.com/p/django-requests/ -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django ignores generated name by custom storage when a callable upload_to is defined
Thanks for the reply, In my opinion, upload_to like the name suggests should point to the directory to upload the file, i didn't unterstand why the mix of directory with the filename in the callable.. I think they are two separate things.. upload_to should handle the directory, and the storage should handle the rest, as if the upload_to were a string.. Gleber On 13 fev, 04:04, Karen Tracey wrote: > On Sat, Feb 13, 2010 at 12:09 AM, Gleber wrote: > > I don't know if this is a bug.. Here is the minimal test case: > > > class CustomStorage(FileSystemStorage): > > def get_valid_name(self, name): > > import random > > return '%s.abc' % (random.randint(100, 999),) > > > def test_uploadto(self,filename): > > return 'aaa/%s' % filename > > > testA = models.FileField(storage=CustomStorage(), upload_to='test') > > testB = models.FileField(storage=CustomStorage(), > > upload_to=test_uploadto) > > > In testA, the file will be saved like "test/123.abc" (as expected) > > > In testB, the file will be saved like "aaa/FILENAME", where FILENAME > > is the name of the local file uploaded by the user, but at least for > > me, is expected that the argument filename is generated by the storage > > as in the testA.. > > If you specify a callable upload_to, then that is the routine that is used > to generate the file name, replacing entirely the default name-generating > routine that would ordinarily combine the specified upload_to directory with > the result of calling the storage get_valid_name(). I'm not sure if that is > a bug or not. > > From one point of view you could say no, that the upload_to implementation > is responsible for calling the storage get_valid_name to ensure whatever > name it wants is valid on the storage backend. So your upload_to should, > instead of using filename directly, run it through > self.storage.get_valid_name and use the result of that to generate the full > upload path+name. > > On the other hand that's not a requirement that appears to be documented > anywhere, and I'm not sure it's a reasonable requirement. It's probably > worth opening a ticket to either document that callable upload_to routines > should be doing this or change things to ensure that the storage > get_valid_name is always called. > > The problem with the latter is we've then got two different sources for > names: callable upload_to and the storage backend, both of which can ignore > the name they are given and return something else entirely. Whichever one is > called last will 'win', and it isn't clear which one that should be. > > Karen -- 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.
Django ignores generated name by custom storage when a callable upload_to is defined
I don't know if this is a bug.. Here is the minimal test case: class CustomStorage(FileSystemStorage): def get_valid_name(self, name): import random return '%s.abc' % (random.randint(100, 999),) def test_uploadto(self,filename): return 'aaa/%s' % filename testA = models.FileField(storage=CustomStorage(), upload_to='test') testB = models.FileField(storage=CustomStorage(), upload_to=test_uploadto) In testA, the file will be saved like "test/123.abc" (as expected) In testB, the file will be saved like "aaa/FILENAME", where FILENAME is the name of the local file uploaded by the user, but at least for me, is expected that the argument filename is generated by the storage as in the testA.. -- 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.
Re: help with Django model and 'choices'
Try surround the values of the constants with Decimal("x"), like:
APLUS = Decimal("4.33")
A = Decimal("4")
AMINUS = Decimal("3.67")
...
On Feb 2, 4:58 pm, raj wrote:
> To populate a ModelMultipleChoiceField of a ModelForm I'd used a hack
> similar to Shawn's initial suggestion. So I hope this will work:
>
> Add to your modelform:
>
> def __init__(self, whatever_there_are_as_args):
> super() # with usual syntax and required_args
> if instance is not None and self.initial is not None:
> self.initial.update({'hp_grade':instance.hp_grade})
> elif instance is not None:
> self.initial = {'hp_grade':instance.hp_grade}
>
> I haven't tested this specific lines but the original code works for
> me.
>
> Rajeesh.
--
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.
Re: select_related(field) doesn't use the default manager of the field
Thanks for the reply, This is much more complex than I thought.. I will stay with the way of two queries, better than one query per object.. Gleber --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
select_related(field) doesn't use the default manager of the field
I have something like this:
class MyManager(models.Manager):
use_for_related_fields = True
def get_query_set(self):
return super(MyManager, self).get_query_set().extra(select =
{'_extra_field':"xxx"})
class ModelA(models.Model):
...
objects = MyManager()
class ModelB(models.Model):
...
ref = models.ForeignKey(ModelA)
When I override the get_query_set() adding extra fields, these fields
aren't available if I execute:
ModelB.objects.all().select_related('ref')
This is a bug? If not, how can I get the extra fields from ModelA
through ModelB with only one query?
I need this cause I have to display a list of 50+ ModelBs and i can't
execute 50+ queries only for that..
Gleber
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
