Re: Aggregation / annotation over results of a subquery

[Malcolm Box]

Thanks Simon, that's exactly what I needed. I had read the aggregation 
documentation, but hadn't figured out how to get it to do what I needed.

Cheers,

Malcolm

On Friday, 20 May 2016 16:52:01 UTC+1, Simon Charette wrote:
>
> Hi Malcom,
>
> I suggest you look into the conditionnal aggregation documentation[1].
>
> from django.db.models import Case, Count, When
>
> Contact.objects.annotate(
> messages_count=Count(
> Case(When(
> messages__recipient=recipient,
> messages__status=Message.STATUS_UNREAD,
> then='messages'
> )),
> )
> ).filter(
> message_count__gte=1,
> ).order_by('-message_count')
>
> Cheers,
> Simon
>
> [1] 
> https://docs.djangoproject.com/en/1.9/ref/models/conditional-expressions/#conditional-aggregation
>
> Le vendredi 20 mai 2016 09:14:10 UTC-4, Malcolm Box a écrit :
>>
>> Hi all,
>>
>> I'm trying to get the ORM to let me sort things based on an annotation, 
>> where that annotation requires a subquery to select items to consider.
>>
>> Concrete example, given models:
>>
>> class Contact(models.Model):
>>name = models.CharField()
>>
>> class Message(models.Model):
>>   sender = models.ForeignKey(Contact, related_name='frm')
>>   recipient = models.ForeignKey(Contact, related_name='to')
>>   unread = models.BooleanField()
>>   send_time = models.DateTimeField(auto_now_add=True)
>>   
>>
>> I want to do things like "for Contact X, create a list of other contacts 
>> ordered by the number of messages to X" or "Order the contacts by number of 
>> unread messages to X"
>>
>> It seems as if annotate/aggregate should be able to do what I want, but I 
>> can't get it to produce a subquery to select the messages to count:
>>
>> Messages.objects.filter(recipient=X).count() - number of messages to X 
>> from all contacts
>>
>> Contact.objects.annotate(msg_count=Count('frm__id')) - gives number of 
>> messages from each contact, but to anyone, not just X
>>
>>
>> Contact.objects.annotate(msg_count=Count(Q(frm__recipient=X)).order_by('msg_count')
>>  
>> - gives the wrong answer for the msg_count (seems to do same as query above)
>>
>> In SQL, what I want is something like:
>>
>> select contact.name, count(message.id) from contact left outer join 
>> message on (contact.id = message.sender_id) where (message.recipient_id 
>> = X.id) group by contact.id
>>
>> But I can't get the ORM to generate SQL that looks like this.
>>
>> Any pointers/help - even "you can't do that using the ORM" would be very 
>> welcome.
>>
>> Cheers,
>>
>> Malcolm
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/10befbe1-f958-4ce4-9c27-f048a57be79e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Aggregation / annotation over results of a subquery

[Malcolm Box]

Hi all,

I'm trying to get the ORM to let me sort things based on an annotation, 
where that annotation requires a subquery to select items to consider.

Concrete example, given models:

class Contact(models.Model):
   name = models.CharField()

class Message(models.Model):
  sender = models.ForeignKey(Contact, related_name='frm')
  recipient = models.ForeignKey(Contact, related_name='to')
  unread = models.BooleanField()
  send_time = models.DateTimeField(auto_now_add=True)
  

I want to do things like "for Contact X, create a list of other contacts 
ordered by the number of messages to X" or "Order the contacts by number of 
unread messages to X"

It seems as if annotate/aggregate should be able to do what I want, but I 
can't get it to produce a subquery to select the messages to count:

Messages.objects.filter(recipient=X).count() - number of messages to X from 
all contacts

Contact.objects.annotate(msg_count=Count('frm__id')) - gives number of 
messages from each contact, but to anyone, not just X

Contact.objects.annotate(msg_count=Count(Q(frm__recipient=X)).order_by('msg_count')
 
- gives the wrong answer for the msg_count (seems to do same as query above)

In SQL, what I want is something like:

select contact.name, count(message.id) from contact left outer join message 
on (contact.id = message.sender_id) where (message.recipient_id = X.id) 
group by contact.id

But I can't get the ORM to generate SQL that looks like this.

Any pointers/help - even "you can't do that using the ORM" would be very 
welcome.

Cheers,

Malcolm

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5136c849-edf5-4618-a3ad-aa09af452e40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Hi Simon,

On Thursday, 10 September 2015 16:57:51 UTC+1, Simon Charette wrote:
>
> Hi Malcolm,
>
> > The system check checks that all the values returned from 
> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
> callable/fields on model, neither of which helps here). With them being 
> created via __getattr__, they don't.
>
> There might be something else going on here but I highly doubt checks are 
> ran against the get_readonly_fields() return value since it's a method 
> bound to a ModelAdmin instance and requires a `request` argument to be 
> called in the first place.
>
>
My mistake, you're entirely correct. The SystemChecks check the 
readonly_fields property, not the result of calling get_readonly_fields().

With the patch to check an instance rather than a class, perhaps I should 
extend the checks to check the result of get_readonly_fields() rather than 
just obj.readonly_fields. What do you think?

Malcolm

Simon
>
> Le jeudi 10 septembre 2015 06:27:13 UTC-4, Malcolm Box a écrit :
>>
>> Hi Simon,
>>
>> I've tried that, and it still fails the same system check.
>>
>> The system check checks that all the values returned from 
>> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
>> callable/fields on model, neither of which helps here). With them being 
>> created via __getattr__, they don't.
>>
>> I'm coming to the conclusion that the right behaviour is to run the 
>> system check against an instance, not the class, since that's what the core 
>> admin code uses.
>>
>> Thanks for the offer to review changes - I'll try to put a patch together 
>> this week.
>>
>> Cheers,
>>
>> Malcolm
>>
>> On 9 September 2015 at 18:17, Simon Charette <chare...@gmail.com> wrote:
>>
>>> Hi Malcom,
>>>
>>> What I meant to suggest is to remove the fields from 
>>> `fields`/`readonly_fields` and dynamically return them in the 
>>> `get_(fields|readonly_fields)` fields method.
>>>
>>> e.g.
>>>
>>> class ThumbnailFieldsAdmin(models.ModelAdmin):
>>> fields = []
>>> readonly_fields = []
>>> thumbnail_fields = []
>>>
>>> def __getattr__(self, name):
>>> if name.endswith('_thumbnail'):
>>> return thumbnail_function
>>> raise AttributeError
>>>
>>> def get_fields(request, obj=None):
>>> fields = super(ThumbnailFieldsAdmin, self).get_fields(request, 
>>> obj=obj)
>>> return self.thumbnail_fields + fields
>>>
>>> def get_readonly_fields(request, obj=None):
>>> readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
>>> request, obj=obj)
>>> return readonly_fields + thumbnail_fields
>>>
>>> But I'm afraid that you'll have to rely on metaclass programming if you 
>>> want the order of fields to be maintained somehow.
>>>
>>> > I therefore suspect that the check is actually borked, and it should 
>>> be checking hasattr(instance, field_name) rather than hasattr(cls, 
>>> field_name)
>>>
>>> The thing is checks are run against ModelAdmin classes and not the 
>>> instances bound to the site they were registered to 
>>> <https://github.com/django/django/blob/dae81c6ec62a76c1f28745ae3642c2d4a37ce259/django/contrib/admin/sites.py#L106-L110>.
>>>  
>>> You could submit a feature request to actually run the test against the 
>>> instances but since this is really and edge case you'd have to provide a 
>>> patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9 
>>> which should enter feature freeze soon enough. I'd be glad to review your 
>>> proposed changes if you're interested.
>>>
>>> Simon
>>>
>>>
>>> Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :
>>>
>>>> Hi Simon,
>>>>
>>>> Thanks for the pointer, but I don't think that helps.
>>>>
>>>> The fields are already declared using the existing fields / 
>>>> readonly_fields attributes on the ExampleAdmin class - and this is what 
>>>> get_fields / get_readonly_fields return. The system check fails because 
>>>> the 
>>>> fields declared don't exist on the ExampleAdmin class nor on the model. 
>>>> Here's the relevant lines from contrib/admin/checks.py:
>>>>
>>>> def _check_readonly_fields_item(self, 

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Ticket filed: https://code.djangoproject.com/ticket/25374

On Thursday, 10 September 2015 11:27:13 UTC+1, Malcolm Box wrote:
>
> Hi Simon,
>
> I've tried that, and it still fails the same system check.
>
> The system check checks that all the values returned from 
> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
> callable/fields on model, neither of which helps here). With them being 
> created via __getattr__, they don't.
>
> I'm coming to the conclusion that the right behaviour is to run the system 
> check against an instance, not the class, since that's what the core admin 
> code uses.
>
> Thanks for the offer to review changes - I'll try to put a patch together 
> this week.
>
> Cheers,
>
> Malcolm
>
> On 9 September 2015 at 18:17, Simon Charette <> wrote:
>
>> Hi Malcom,
>>
>> What I meant to suggest is to remove the fields from 
>> `fields`/`readonly_fields` and dynamically return them in the 
>> `get_(fields|readonly_fields)` fields method.
>>
>> e.g.
>>
>> class ThumbnailFieldsAdmin(models.ModelAdmin):
>> fields = []
>> readonly_fields = []
>> thumbnail_fields = []
>>
>> def __getattr__(self, name):
>> if name.endswith('_thumbnail'):
>> return thumbnail_function
>> raise AttributeError
>>
>> def get_fields(request, obj=None):
>> fields = super(ThumbnailFieldsAdmin, self).get_fields(request, 
>> obj=obj)
>> return self.thumbnail_fields + fields
>>
>> def get_readonly_fields(request, obj=None):
>> readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
>> request, obj=obj)
>> return readonly_fields + thumbnail_fields
>>
>> But I'm afraid that you'll have to rely on metaclass programming if you 
>> want the order of fields to be maintained somehow.
>>
>> > I therefore suspect that the check is actually borked, and it should be 
>> checking hasattr(instance, field_name) rather than hasattr(cls, field_name)
>>
>> The thing is checks are run against ModelAdmin classes and not the 
>> instances bound to the site they were registered to 
>> <https://github.com/django/django/blob/dae81c6ec62a76c1f28745ae3642c2d4a37ce259/django/contrib/admin/sites.py#L106-L110>.
>>  
>> You could submit a feature request to actually run the test against the 
>> instances but since this is really and edge case you'd have to provide a 
>> patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9 
>> which should enter feature freeze soon enough. I'd be glad to review your 
>> proposed changes if you're interested.
>>
>> Simon
>>
>>
>> Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :
>>
>>> Hi Simon,
>>>
>>> Thanks for the pointer, but I don't think that helps.
>>>
>>> The fields are already declared using the existing fields / 
>>> readonly_fields attributes on the ExampleAdmin class - and this is what 
>>> get_fields / get_readonly_fields return. The system check fails because the 
>>> fields declared don't exist on the ExampleAdmin class nor on the model. 
>>> Here's the relevant lines from contrib/admin/checks.py:
>>>
>>> def _check_readonly_fields_item(self, cls, model, field_name, label):
>>> if callable(field_name):
>>> return []
>>> elif hasattr(cls, field_name):
>>> return []
>>> elif hasattr(model, field_name):
>>> return []
>>> else:
>>> try:
>>> model._meta.get_field(field_name)
>>> except FieldDoesNotExist:
>>> return [
>>> checks.Error(
>>> "The value of '%s' is not a callable, an 
>>> attribute of '%s', or an attribute of '%s.%s'." % (
>>> label, cls.__name__, model._meta.app_label, 
>>> model._meta.object_name
>>> ),
>>> hint=None,
>>> obj=cls,
>>> id='admin.E035',
>>> )
>>> ]
>>> else:
>>> return []
>>>
>>> If the thumbnail fields were defined as methods on the ExampleAdmin, all 
>>> would be fine e.g.:
>>>
>>> class ExampleAdmin(models.ModelAdmin):
>>&

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Hi Simon,

I've tried that, and it still fails the same system check.

The system check checks that all the values returned from
get_readonly_fields exist as class attributes on the ModelAdmin (or are
callable/fields on model, neither of which helps here). With them being
created via __getattr__, they don't.

I'm coming to the conclusion that the right behaviour is to run the system
check against an instance, not the class, since that's what the core admin
code uses.

Thanks for the offer to review changes - I'll try to put a patch together
this week.

Cheers,

Malcolm

On 9 September 2015 at 18:17, Simon Charette <charett...@gmail.com> wrote:

> Hi Malcom,
>
> What I meant to suggest is to remove the fields from
> `fields`/`readonly_fields` and dynamically return them in the
> `get_(fields|readonly_fields)` fields method.
>
> e.g.
>
> class ThumbnailFieldsAdmin(models.ModelAdmin):
> fields = []
> readonly_fields = []
> thumbnail_fields = []
>
> def __getattr__(self, name):
> if name.endswith('_thumbnail'):
> return thumbnail_function
> raise AttributeError
>
> def get_fields(request, obj=None):
> fields = super(ThumbnailFieldsAdmin, self).get_fields(request, obj
> =obj)
> return self.thumbnail_fields + fields
>
> def get_readonly_fields(request, obj=None):
> readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
> request, obj=obj)
> return readonly_fields + thumbnail_fields
>
> But I'm afraid that you'll have to rely on metaclass programming if you
> want the order of fields to be maintained somehow.
>
> > I therefore suspect that the check is actually borked, and it should be
> checking hasattr(instance, field_name) rather than hasattr(cls, field_name)
>
> The thing is checks are run against ModelAdmin classes and not the
> instances bound to the site they were registered to
> <https://github.com/django/django/blob/dae81c6ec62a76c1f28745ae3642c2d4a37ce259/django/contrib/admin/sites.py#L106-L110>.
> You could submit a feature request to actually run the test against the
> instances but since this is really and edge case you'd have to provide a
> patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9
> which should enter feature freeze soon enough. I'd be glad to review your
> proposed changes if you're interested.
>
> Simon
>
>
> Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :
>
>> Hi Simon,
>>
>> Thanks for the pointer, but I don't think that helps.
>>
>> The fields are already declared using the existing fields /
>> readonly_fields attributes on the ExampleAdmin class - and this is what
>> get_fields / get_readonly_fields return. The system check fails because the
>> fields declared don't exist on the ExampleAdmin class nor on the model.
>> Here's the relevant lines from contrib/admin/checks.py:
>>
>> def _check_readonly_fields_item(self, cls, model, field_name, label):
>> if callable(field_name):
>> return []
>> elif hasattr(cls, field_name):
>> return []
>> elif hasattr(model, field_name):
>> return []
>> else:
>> try:
>> model._meta.get_field(field_name)
>> except FieldDoesNotExist:
>> return [
>> checks.Error(
>> "The value of '%s' is not a callable, an
>> attribute of '%s', or an attribute of '%s.%s'." % (
>> label, cls.__name__, model._meta.app_label,
>> model._meta.object_name
>> ),
>> hint=None,
>> obj=cls,
>> id='admin.E035',
>> )
>> ]
>> else:
>> return []
>>
>> If the thumbnail fields were defined as methods on the ExampleAdmin, all
>> would be fine e.g.:
>>
>> class ExampleAdmin(models.ModelAdmin):
>>fields = ['image', 'image_thumbnail']
>>
>>def image_thumbnail(self, obj):
>>return "" % obj.image.url
>>
>> That's fine, but if there's lots of image fields (with a variety of
>> names) spread over several ModelAdmin classes, then you end up with a lot
>> of duplicated code. The normal solution then is to refactor the code. And
>> that's where I get stuck - I can't see (short of metaclass programming!)
>> how to inject the methods into the class such that the system check
>> succeeds.
>>
>> I therefore 

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Hi Simon,

Thanks for the pointer, but I don't think that helps.

The fields are already declared using the existing fields / readonly_fields
attributes on the ExampleAdmin class - and this is what get_fields /
get_readonly_fields return. The system check fails because the fields
declared don't exist on the ExampleAdmin class nor on the model. Here's the
relevant lines from contrib/admin/checks.py:

def _check_readonly_fields_item(self, cls, model, field_name, label):
if callable(field_name):
return []
elif hasattr(cls, field_name):
return []
elif hasattr(model, field_name):
return []
else:
try:
model._meta.get_field(field_name)
except FieldDoesNotExist:
return [
checks.Error(
"The value of '%s' is not a callable, an attribute
of '%s', or an attribute of '%s.%s'." % (
label, cls.__name__, model._meta.app_label,
model._meta.object_name
),
hint=None,
obj=cls,
id='admin.E035',
)
]
else:
return []

If the thumbnail fields were defined as methods on the ExampleAdmin, all
would be fine e.g.:

class ExampleAdmin(models.ModelAdmin):
   fields = ['image', 'image_thumbnail']

   def image_thumbnail(self, obj):
   return "" % obj.image.url

That's fine, but if there's lots of image fields (with a variety of names)
spread over several ModelAdmin classes, then you end up with a lot of
duplicated code. The normal solution then is to refactor the code. And
that's where I get stuck - I can't see (short of metaclass programming!)
how to inject the methods into the class such that the system check
succeeds.

I therefore suspect that the check is actually borked, and it should be
checking hasattr(instance, field_name) rather than hasattr(cls, field_name)

So I see three possibilities, in order of probability:

   1. I'm being dumb, and there's an easy way to dynamically create
   attributes on a ModelAdmin that passes system checks
   2. The system check is incorrect, and should allow dynamically created
   attributes on ModelAdmin when validating fields
   3. Metaclass programming is really the right way to do this


Malcolm

On 9 September 2015 at 02:23, Simon Charette <charett...@gmail.com> wrote:

> Hi Malcom!
>
> I would suggest you have a look at the ModelAdmin.get_fields()
> <https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_fields>
> method to append your thumbnail read-only field names.
>
> As documented
> <https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fields>,
> just make sure you also override ModelAdmin.get_readonly_fields()
> <https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_readonly_fields>
> to return them as well.
>
> Cheers,
> Simon
>
> Le mardi 8 septembre 2015 13:31:47 UTC-4, Malcolm Box a écrit :
>>
>> Hi,
>>
>> I'm trying to add a dynamic method to a ModelAdmin so that I can have
>> automatically generated thumbnail fields for any image by simply adding
>> '_thumbnail' to the field definitions - which saves a lot of
>> code when there's a load of admin classes with image fields that need
>> thumbnails.
>>
>> e.g.
>>
>> class ThumbnailMixin(object):
>> def getattr(self, name):
>>  if name.endswith('_thumbnail'):
>>   # ... generate appropriate thumbnail method and return
>>   return thumbnail_function
>>  else:
>>  raise AttributeError
>>
>> class ExampleAdmin(models.ModelAdmin, ThumbnailMixin):
>>  fields = ['image_thumbnail', 'image', ...]
>>
>> This worked fine in Django 1.6/1.7, but it's now failing in 1.8 with a
>> SystemCheckError (admin.E035 / admin.E108). If I silence the error, the
>> admin actually works fine, but that feels icky.
>>
>> The check fails because it checks for the field being on the ExampleAdmin
>> class, not on an instance - whereas the admin always uses an instance, so
>> it works.
>>
>> What's the "right" way to do this in the 1.8 world - I've considered a
>> custom metaclass, but that feels like overkill for a simple task like this.
>> Should this even work, and if so is it a bug in the check framework?
>>
>> Cheers,
>>
>> Malcolm
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit

Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Hi,

I'm trying to add a dynamic method to a ModelAdmin so that I can have 
automatically generated thumbnail fields for any image by simply adding 
'_thumbnail' to the field definitions - which saves a lot of 
code when there's a load of admin classes with image fields that need 
thumbnails.

e.g.

class ThumbnailMixin(object):
def getattr(self, name):
 if name.endswith('_thumbnail'):
  # ... generate appropriate thumbnail method and return
  return thumbnail_function
 else:
 raise AttributeError

class ExampleAdmin(models.ModelAdmin, ThumbnailMixin):
 fields = ['image_thumbnail', 'image', ...]

This worked fine in Django 1.6/1.7, but it's now failing in 1.8 with a 
SystemCheckError (admin.E035 / admin.E108). If I silence the error, the 
admin actually works fine, but that feels icky.

The check fails because it checks for the field being on the ExampleAdmin 
class, not on an instance - whereas the admin always uses an instance, so 
it works.

What's the "right" way to do this in the 1.8 world - I've considered a 
custom metaclass, but that feels like overkill for a simple task like this. 
Should this even work, and if so is it a bug in the check framework?

Cheers,

Malcolm

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/987461ae-f455-44f7-9c61-935a6d412c49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't saving a related model update the _id field?

[Malcolm Box]

On Monday, 9 June 2014 03:08:21 UTC+1, Russell Keith-Magee wrote:

>
> On Sun, Jun 8, 2014 at 10:34 PM, Malcolm Box <mal...@tellybug.com 
> > wrote:
>
>> I'm confused by Django's behaviour when saving related models. Take for 
>> example:
>> 
>> I kind of understand this, but it's not obvious to me why Django doesn't 
>> at least try to save the related object first
>>
>
> Ok - so how does Django decide that the related object needs to be saved? 
>
> If it saves all related objects, then saving one object could result in a 
> save call being invoked on every object in the database (since y points to 
> x, which points to a, which points to b,…). I hope we can agree that a 
> cascading save like this would be a bad idea.
>
> If it's not *every* related object, then we need to make a decision - 
> which ones get saved? Ok - so lets say we just save the newly created 
> objects (i.e., objects with no primary keys. 
>
> That means that the following would work:
>
> x = X(value=37)
> y = Y(x=x)
> y.save()
>
> and on retrieval, y.x.value == 37. Sure - that makes sense. But what about:
>
> x = X(value=37)
> x.save()
> x.value = 42
> y = Y(x=x)
> y.save()
>
> and on retrieval, y.x.value == 37. Huh? Why? Oh - it's because in *that* 
> case, x was already in existence, so it wasn't re-saved as a result of y 
> being created. So now we've got inconsistent behaviour, depending on when 
> save() has been called on an object.
>

Sure, that would be the side effect of assigning a pre-existing object. The 
use case I'm thinking of is creating an entire tree of un-saved objects in 
memory, and then having save() on the root Do The Right Thing. If that was 
inconsistent with assigning pre-existing objects, I could live with it.


> The only way I can see to rectify *this* problem would be to keep a track 
> of every value that has been modified, and save any "modified" objects. 
> This is in the realm of the possible -- and it has been proposed in the 
> past -- but it means carrying a lot of accounting baggage around on *every* 
> attribute change. 
>

Surely the extra baggage is a modified flag, set on each object when any 
attribute is changed? Then  save() can "simply" follow relationships and 
save any modified objects.

 
>
>> B) y.x.save(); y.save() also throws an integrity error because y.x_id is 
>> None. 
>>
>> However, y.x.id is not None, so I don't understand why it can't update 
>> y.x_id (and thus make the save succeed).
>>
>> C) y.x.save(); y.x = y.x; y.save() - succeeds, but I don't see why the 
>> y.x = y.x is needed.
>>
>> Is this a deliberate design decision, something I'm misunderstanding, or 
>> a bug/implementation artefact?
>>
>
> It's a deliberate design decision, for reasons that my example above 
> hopefully makes clear. The reason the re-assignment is needed in your 
> example is because y.x implies a query; if you directly save the original 
> object (i.e., x.save(), not y.x.save()), you should find the reassignment 
> isn't needed.
>

Ah, the issue I'm running into is that the point at which y.save() is 
called is separated from where y.x was assigned - so I no longer have a 
reference to the original object (except ... via y.x, so I guess I don't 
understand why that doesn't work the same as saving the original x...) 

Thanks for the explanation Russ, much appreciated.

Cheers,

Malcolm

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/44414d31-db07-4c91-a6e2-60a9f6be7400%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to receive json data using HTTP POST request in Django 1.6?

[Malcolm Box]

Simplest answer is to use Django Rest Framework, which makes this extremely 
easy.

Malcolm

On Monday, 9 June 2014 11:20:05 UTC+1, Alok Singh Mahor wrote:
>
> Hi all,
>
> I am trying to receive JSON data using HTTP POST in django 1.6.
> I tried using request.POST['data'], request.raw_post_data, request.body 
> but none is working for me. 
> I have posted question and code at 
> http://stackoverflow.com/questions/24068576/how-to-receive-json-data-using-http-post-request-in-django-1-6
>
> please tell me how to achieve this in django 1.6
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/78563526-cf0a-4cfc-b8f4-e1551eb4fa51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: execute a code at a particular date and time (aperidic task) in django

[Malcolm Box]

The canonical answer to this is to use Celery, which provides a task queue 
for any background/scheduled tasks you want to use.

It's pretty easy to get set up, and works well.

Malcolm

On Tuesday, 10 June 2014 06:37:46 UTC+1, Rini Michael wrote:
>
> Hi,
> i am looking for a way where i can execute a task at a particular date and 
> time, i tried apscheduler for this purpose but i am finding some difficulty 
> while integerating with django. can anyone help me with this
> the flow is
> user will specify a particular date and time through GUI --> submit --> 
> the task will be executed at the particular date and time the user mentioned
> i have tried the following in django (Apscheduler approach)
>
> import time
> from datetime import datetime
> from apscheduler.scheduler import Scheduler
> import os
> def func1(self,exec_date):
> from_time = datetime.datetime.strptime("2014-05-29 13:56:59",'%Y-%m-%d 
> %H:%M:%S')
> self.exec_date = datetime.datetime ( 
> from_time.year,from_time.month,from_time.day,from_time.hour,from_time.minute)
> return exec_date
> sched = Scheduler()
> sched.start()
> def my_job(test,exec_date):
> print test
> os.system("python C://Python27/Lib/idlelib/tim.py")
> job = sched.add_date_job(my_job,exec_date, ['hello'])
>
>
> the issue i am facing is the input that the user gives (date n time) is in 
> forms.py ,i have written the code for apscheduler in views.py and i call 
> the function through urls.py but the code doesn't really seem to work,can 
> anyone suggest me how apscheduler works with django or guide me with some 
> links which give information about that
>
> Thanks in advance
>
> Thanks and regards 
> Rini
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/782c7d3c-735f-4eaa-9f6d-6f7692268003%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why doesn't saving a related model update the _id field?

[Malcolm Box]

I'm confused by Django's behaviour when saving related models. Take for 
example:

class X(models.Model):
pass

class Y(models.Model):
   x = models.ForeignKey(X)

Now if I create some objects (unsaved):

x = X()
y = Y(x=x)

All well so far. But now odd things happen when I save:

A) y.save() throws an integrity error because there's no PK for x

I kind of understand this, but it's not obvious to me why Django doesn't at 
least try to save the related object first

B) y.x.save(); y.save() also throws an integrity error because y.x_id is 
None. 

However, y.x.id is not None, so I don't understand why it can't update 
y.x_id (and thus make the save succeed).

C) y.x.save(); y.x = y.x; y.save() - succeeds, but I don't see why the y.x 
= y.x is needed.

Is this a deliberate design decision, something I'm misunderstanding, or a 
bug/implementation artefact?

I'm running into this with serialization in Django Rest Framework - my API 
provides a facade over something that's actually stored across two models, 
so when creating the resource I want to deserialise the data into the two 
related models. DRF serializers by default return unsaved versions of the 
model, but this is broken by the above.

Any insight into what's going on and why would be much appreciated.

Cheers,

Malcolm


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/21f29ffc-29ba-40f3-9143-25fed227d4af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: memcached - Errors and Solution - please provide comments!

[Malcolm Box]

On 10 November 2011 08:54, ionic drive  wrote:

> Hello django friends,
>
> Problems:
> 
> 1) MemcachedKeyCharacterError: Control characters not allowed
> 2) MemcachedKeyLengthError: Key length is > 250
>
>
The obvious solution is not to generate keys with these properties.


>def _smart_key(self, key):
>"Truncate all keys to 250 or less and remove control characters"
>return smart_str(''.join([c for c in key
>if ord(c) > 32 and ord(c) !=
> 127]))[:250]
>
>
That looks like a very dangerous, and not very smart key function. Since
you're truncating the key, two keys that should be different could end up
pointing to the same place. That will result in very difficult to track
down bugs.

If you really have values that are longer than 255 characters, I'd suggest
running it through a hash function (e.g. MD5) that has a low probability of
collision, and then use that.

E.g. if the key was "poll:question:choice:a very long choice here that
takes up 255 characters" I'd turn it into
"poll:question:choice:"

Malcolm

-- 
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: Caching at model class level

[Malcolm Box]

On 4 November 2011 07:02, Thomas Guettler  wrote:

> Am 03.11.2011 18:42, schrieb Tom Evans:
> > On Thu, Nov 3, 2011 at 2:22 PM, Thomas Guettler  wrote:
> >> Hi,
> >>
> >> I try to reduce the number of db-queries in my app.
> >>
> >> There is a model which changes almost never. It is like a "type of
> ticket"
> >> in a trouble ticket system.
> >>
> >> On one page there are seven SQL-Queries (SELECT  FROM ticket_type
> where id=123) which of course always return
> >> the same result.
>

How are you getting 7 queries the same? Would select_related solve the
problem by doing it all in one query?

Malcolm

-- 
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: Login problems under heavy load

[Malcolm Box]

On 24 October 2011 12:01, Tom Evans  wrote:

> On Fri, Oct 21, 2011 at 6:15 PM, Alpesh Gajbe 
> wrote:
> >
> >  File "/usr/local/lib/python2.6/dist-packages/django/http/__init__.py",
> > line 296, in read
> >   return self._stream.read(*args, **kwargs)
> >
> > IOError: request data read error
> >
>
> tl;dr - the user got bored waiting, pressed 'stop' on their browser.
>
>
Although that's almost always true, it *is* possible to see "request data
read error" on WSGI that isn't caused by the user hitting stop. See for
example the ModWSGI FAQ.

Malcolm

-- 
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 tutorial hasn't received an update for 1.3

[Malcolm Box]

Hi,

If you've figured this stuff out, how about writing some of the tutorial
yourself and submitting a patch?

Trying to teach someone else is the best way to figure out if you really
understand something, and you'd be contributing to keeping the Django
documentation great.

Malcolm

On 31 October 2011 07:08, Kevin <kveron...@gmail.com> wrote:

> I keep checking the tutorial page for version 1.3 hoping to see some
> new content related to the class-based views or at least some of the
> promised future tutorials.  The tutorial still has the function-based
> views, and no new updates since I first went through it on the 1.2
> release.
>
> I know the function views work in 1.3, but shouldn't the tutorial be
> using the latest features included in 1.3 so that new users coming to
> Django begin learning the newest features, such as class-based views.
>
> I'm still a dinosaur and using Django 1.2 and haven't yet dived into
> class-based views, and when I do, I would love a great tutorial on how
> to proceed.  I plan on learning Django 1.3's newest features very soon
> to keep myself up to speed and see if my current apps are fully
> compatible.
>
> Are there any updates on when we will see the following new tutorial
> sections:
> -Advanced form processing
> -Using the RSS framework
> -Using the cache framework
> -Using the comments framework
> -Advanced admin features: Permissions
> -Advanced admin features: Custom JavaScript
>
> I figured out most of this on my own, as they are pretty
> straightforward, still haven't dived into custom javascript in the
> admin yet.
>
> --
> 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.
>
>


-- 
Malcolm Box
malcolm@gmail.com

-- 
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: CAS and Django cache

[Malcolm Box]

Yes, get followed by set can lead to data loss. 

What you want is cache.add(). This sets the value if and only if there is no 
existing value. Its atomic on backends that support it - notably memcached.  

Sent from my iPhone, please excuse any typos

On 27 Oct 2011, at 07:26, Dan Julius  wrote:

> Couldn't that potentially overwrite a value set by a different thread?
> 
> Dan
> 
> On Thu, Oct 27, 2011 at 7:13 AM, Kurtis Mullins  
> wrote:
> umm, I'm not sure if "check-and-set" is some cache-specific lingo or not. But 
> if you want to see if a value isn't set, check to see if it's None type... 
> example:
> 
> if cache.get('key') is None:
> cache.set('key', 'value', cache_seconds)
> 
> Sorry if that's not at all what you're talking about :)
> 
> 
> On Wed, Oct 26, 2011 at 6:29 PM, dmitry b  wrote:
> Can I do check-and-set operations using Django's cache api?
> 
> 
> Thanks
> D.
> 
> --
> 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.
> 
> 
> -- 
> 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.
> 
> -- 
> 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.

-- 
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: Is it possible to run from Django script?

[Malcolm Box]

On 20 September 2011 21:36, Stone  wrote:

> Dear users,
>
> I have simple question which regards with running script from view.py.
> 
> Is it possible to do that over subprocess command?
>
>
Yes, you can run a script from within your view. Whether you *should* or not
depends largely on how long the script might take to run. While it's running
the Django instance serving the user's request and the user's browser will
hang waiting for it to complete, so if it's going to take a while then you'd
be better off running the script using something like Celery.

Cheers,

Malcolm

-- 
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 and thrift

[Malcolm Box]

On 8 September 2011 03:27, Li Lirong  wrote:

> Hi,
> Thank you for your comments.  I am new to both django and thrift.  I
> am hosting my service with a shared web hosting server.  That's why I
> want to use django to expose a thrift API.  Basically, what I want is
> to have a web service that can be consumed by both python and c++.  Do
> you think this is possible with django?
>
>
It's entirely possible, but I'd suggest not using Thrift as the transport
protocol in this case. You'd be better off having a REST over HTTP service
with payloads in JSON.

M

-- 
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: In unitTest, GET Formset returns 302 instead of 200

[Malcolm Box]

On 7 September 2011 11:52, MATHIEU  wrote:

> For the GET method, I have tried the following code:
> 
>def test_patron_phone_get_form(self):
>self.client.login(usernamer='alex...@e.com',
> password='alex')
>response = self.client.get(reverse('patron_edit_phone'))
>self.assertEquals(response.status_code, 200)
> 
> But this doesn't work. Instead of getting a status_code=200, I get a
> status_code=302. Why?
>

If this is a cut'n'paste of your code, you have a typo in the
self.client.login() call - you're passing "usernamer" not "username"

Malcolm

-- 
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: Pagination of more than one field

[Malcolm Box]

On 7 September 2011 14:57, OC  wrote:

> Thank you very much for your reply,
> I changed it but I guess Im doing something wrong cause it still
> doesnt work:
> It tries to go to the right page now, but provides nothing although I
> know there's more than one page:
>
> in views.py
> movies_page= int(request.GET.get('page','1'))
>try:
>moviesp = movpaginator.page(movies_page)...
>
> in the template:
>   {% if actors.has_previous %}
> src="{{ MEDIA_URL }} images/preview.png">
>{% else %}
>
>
> You're setting the movies_page request parameter in the URL you're
generating, but you're reading the *page* request parameter in the view
function.

Change to "movies_page = int(request.GET.get('movies_page', 1))" and it
should work

-- 
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 and thrift

[Malcolm Box]

On 7 September 2011 07:18, leon  wrote:

> Hi,
>
> I have one question.  Is it possible to use Django to write thrift
> (http://thrift.apache.org/) formated web service? If it is possible,
> is there any sample?
>
>
Possible, maybe. But almost certainly the wrong thing to do.

Thrift is a binary protocol that doesn't look much like HTTP. Attempting to
use a web framework to handle it will cause grief.

Use the Thrift Python bindings to write a server, either a straight Thrift
server or using Twisted. Then if you need access to things like the Django
ORM then use those in the server.

Don't try to tie handling Thrift into the Django
URL/HttpRequest/HttpResponse cycle or you'll go mad.

Malcolm

-- 
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: Pagination of more than one field

[Malcolm Box]

On 7 September 2011 08:25, OC  wrote:

> also attaching relevant parts of view.py:
>
>
>  movpagin = Paginator(movies, 12)
>
>page = int(request.GET.get('page','1'))
>try:
>moviesp = movpagin.page(page)
>except PageNotAnInteger:
># If page is not an integer, deliver first page.
>moviesp = movpagin.page(1)
>except EmptyPage:
># If page is out of range (e.g. ), deliver last page of
> results.
>moviesp = movpagin.page(movpagin.num_pages)
>
>actpagin = Paginator(actors, 8)
>
>page = int(request.GET.get('page','1'))
>

There's the problem right there. You're using the same page variable for
both sides, so inevitably you'll find they move together.

Put the movies page into a variable called movie_page, and the actors into
actor_page. Update your links in the template to use the right query for the
prev/next and all should work fine.

Malcolm

-- 
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: Problem updating data

[Malcolm Box]

Instead of counting the inactive, try counting the active ones. If that
count doesn't go up by one, I'd suspect something's dodgy in your Entry
model's save() that means it doesn't write successfully to the db.

You could debug by doing:

from django.db import connection
connection.queries
e1.save()
connection.queries

to see what the SQL generated was.

Then start looking at your database to see what it's doing.

Malcolm

On 23 August 2011 23:08, Karen McNeil <karenlmcn...@gmail.com> wrote:

> No, that's not the problem. Even if I redo the query now, I still get
> the same count (see below). And, like I said, the change does not show
> up in the admin either -- THE VALUE HAS NOT BEEN CHANGED.
>
> This behavior is so unexpected I'm not sure how to even begin trouble-
> shooting it.
>
> ~Karen
>
> PS -- What's wrong with querying by "active=0"? I did it that way
> because that's what the admin interface does for filters... is there
> any difference?
>
>
> NEW SHELL SESSION FROM TODAY, TESTING SAME THING:
>
> >>> from dictionary.models import Entry
> >>> entries = Entry.objects.filter(active=False)
> >>> entries.count()
> 3642
> >>> e1 = entries[0]
> >>> e1
> 
> >>> e1.active
> False
>
> --
> 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.
>
>


-- 
Malcolm Box
malcolm@gmail.com

-- 
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: Help installing django-sentry

[Malcolm Box]

Post your urls.py file - it looks like you have a pattern that is over 
aggressively matching /sentry as a poll. 

Malcolm

Sent from my iPhone, please excuse any typos

On 21 Aug 2011, at 21:18, tharshan muthulingam  wrote:

> Hi, 
> I have been having alot of trouble trying to install and run django-sentry. 
> My project directory is ~/django_projects/Project
> 
> Inside there i have the simple polls app from the tutorial, and I have 
> installed sentry using pip. I have added it to the list of installed apps.
> 
> When I go to the sentry directory I got this error:
> http://127.0.0.1:8000/sentry/
> 
> ViewDoesNotExist at /sentry/Tried result in module polls.views. Error was: 
> 'module' object has no attribute 'result'
> 
> I honestly have no clue what that means, and I would really appreciate some 
> help with fixing this.
> 
> Thank you!!
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-users/-/XAczs-79BVMJ.
> 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.

-- 
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: Best approach to handling different types of Users

[Malcolm Box]

On 19 August 2011 03:37, Andre Terra  wrote:

> Until you install some third party app that accesses
> User.objects.all() and then suddenly nothing works as it's supposed
> to.
>
>
I hear this a lot that "things will break" if you subclass User. However, I
haven't seen anyone share a concrete example of *how* things go wrong.

Anyone got a good example to scare the children with?

Malcolm

-- 
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 Test Corrupted Test Data

[Malcolm Box]

According to the SO post, you're seeing TestObject.objects.all().count()
return two different values on successive calls.

That is basically impossible unless there's something else getting in there
and doing stuff to your db.

Alternatively, does your subclass of TestCase correctly call
super(MyTestCase, self).setUp() and other superclass methods to get the DB
setup right?

Malcolm

On 19 August 2011 22:05, patjenk <patj...@gmail.com> wrote:

> As I understand it, the database should be reset between each test. To
> me this means that unless the variable being examined is an attribute
> of self, the tests shouldn't affect each other.
>
> Could it be possible that there is a sqllite subtly that delays the
> reset of the table count and it affects the outcome of the test in
> this instance?
>
> On Aug 19, 3:43 pm, bik...@gmail.com wrote:
> > Could it be that the tests affect each other (when ran in a series)?
> >
> > Sent from my BlackBerry® from Vodafone
> >
> > -Original Message-
> > From: dm03514 <dm03...@gmail.com>
> >
> > Sender: django-users@googlegroups.com
> > Date: Fri, 19 Aug 2011 12:13:24
> > To: Django users<django-users@googlegroups.com>
> > Reply-To: django-users@googlegroups.com
> > Subject: Django Test Corrupted Test Data
> >
> > I have a test class that subclasses django.test.TestCase which has
> > about 5 different tests in it. When I run my full test suite (using
> > nose, and specifying sqlite as backend) there are a series of
> > failures. When I go to debug the tests, running them individually,
> > they pass fine.
> >
> > http://stackoverflow.com/questions/7126172/django-testrunner-incorrec...
> >
> > --
> > 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 athttp://
> 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-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.
>
>


-- 
Malcolm Box
malcolm@gmail.com

-- 
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: how to invalidate per-view cache?

[Malcolm Box]

On 19 August 2011 23:32, galgal <weglarek.rob...@gmail.com> wrote:

> I want to use per-view 
> cache<https://docs.djangoproject.com/en/1.3/topics/cache/#the-per-view-cache>.
> I know how it's working, but where's the problem? How can I invalidate that
> cache? I must do it each time database records are changed. There is no info
> about how to do that:/


You'll need to use the low-level cache API to invalidate the individual
cache entries. Hook up a post_save handler to your model, figure out the
key(s) for the views affected and use cache.delete() to remove the entry.

Malcolm


-- 
Malcolm Box
malcolm@gmail.com

-- 
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: Specific models without a database table

[Malcolm Box]

On 20 August 2011 02:33, Kristofer Pettijohn wrote:

> Hello,
>
> Is it possible to create specific models without a database table?
>
>
Yes, it's possible. You want the "managed" attribute on the model - see
https://docs.djangoproject.com/en/1.3/ref/models/options/#managed

This will prevent Django from creating or modifying the db table


> Basically what I would like to do is create an email account management
> application that ties into my existing mail server and its API.  I would
> like Django to have a Users model and keep track of users, a Domains model
> to keep track of the email domains for the user, but I don't want it to
> actually keep track of email addresses.  Once the user is in the
> application, they will go into the "EmailAccount" model and I simply want
> the model to query my mail server via its SOAP API.  So when they
> create/delete/edit email accounts, there will be form pages and simple
> validation done by Django, but the actual work will be done by connecting to
> the mail servers API and not a database.
>
>
Is this possible?
>
>
That is substantially harder, but could be possible. The main problem is
that the Django ORM will want to write SQL queries when there's a link to
the EmailAccount model.

Your best bet is probably a proxy model that contains a reference to the
relevant API record (e.g. the email address identifier or whatever the API
uses), and then a custom save() method that writes the values out to the DB.
You can use the Django form logic etc without it needing to be backed by a
model.

It will largely depend on how you want the EmailAccount to look - the closer
you want it to work to a standard ORM model, the more work you'll have to do
to trick things. If it's a simple field that isn't used for queries, then
you could look at creating a custom field type that knows how to read/write
the values to the API.

All the above advice is worth exactly what you paid for it!

Malcolm

-- 
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 for a front end designer

[Malcolm Box]

On 2 August 2011 18:49, bruno desthuilliers
<bruno.desthuilli...@gmail.com>wrote:

>
> As far as I'm concerned, OSX is a pain (as a programming platform)
> whaver language / techno you want to use.
>
>
Don't be put off by this - it's certainly not my (nor many, many other
people's) experience of programming on OS X.

>From my experience, it rocks as a place to program:

- If you want to write Mac or iPhone code, XCode is an amazing IDE
- If you want to write stuff to deploy onto a Unix server, you have all the
tools, libraries and stuff already working (OS X is Unix under the hood) -
but cf Linux the available tools (editors etc) are superior.
- If you want to write Windows code then you can run a Windows VM and have
everything safely sealed off
- It's all wrapped in a package that "just works" and gets out of the way.
So you don't have to spend hours twiddling obscure X-Windows settings to get
a desktop that works. Oh, and the battery life is good.

Malcolm

-- 
Malcolm Box
malcolm@gmail.com

-- 
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] Get request URL

[Malcolm Box]

The best you can do is look for a Referrer header in the request:

request.META['HTTP_REFERER']

which should be the URL of the originating page. However that may or may not
be there depending on user's browser etc etc.

Malcolm

On 3 August 2011 00:41, He Jibo <hej...@gmail.com> wrote:

> Hi, Djangoers,
>
> I am trying to write a page rank banner. *I need your help on how to get
> the request UR*L.  I want the function looks like this. If I put the
> following html snippet in a URL, for example,
> http://www.homesecurity361.com/index.html, I want the following code to
> show the page rank of this URL. I know how to calculate page rank after
> getting the URL. My problem is,* if the following code is put at
> http://www.homesecurity361.com/index.html, how can my own server,
> http://www.ueseo.net know which URL is requesting the image banner*, *
> http://www. ueseo.net/pagerank.gif* ? Thanks so much.
>
> *http://www.ueseo.net/; title="Search Engine Optimization"
> target="_blank">http://www. ueseo.net/pagerank.gif" alt="Search
> Engine Optimization" style="border: 0;">
> *
>
> ---
> He Jibo
> Department of Psychology,
> Beckman Institute for Advanced Science and Technology
> University of Illinois, Urbana Champaign,
> 603 East Daniel St.,
> Champaign, IL 61820
> website: www.hejibo.info
>
> --
> 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.
>



-- 
Malcolm Box
malcolm@gmail.com

-- 
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: Recommendations for load testing/profiling a django site server?

[Malcolm Box]

On 22 July 2011 13:52, Jacob Kaplan-Moss  wrote:

> On Thu, Jul 21, 2011 at 5:03 PM, br  wrote:
> > I am running on a Linode 768 VPS and may have some stuff going live
> > before too long.  I'm wondering what the best way to guage whether I
> > have enough bandwidth/CPU/memory to handle a significant amount of
> > traffic is and/or to get an idea of the types of loads the site can
> > handle before i need to upgrade.
>
>
TSung and JMeter are both good. Unless you're expecting insanely high loads,
then the best bet is probably JMeter and/or apachebench.

Malcolm

-- 
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: Problem with relationships in models

[Malcolm Box]

A guess, but are you sure syncdb created the tables? Ie have you checked
using mysql, or manage.py dbshell that the tables are really there?

Syncdb only creates tables for a model the first time it is run - after that
it won't track updates. So if you ran it, then added the relationship, then
ran again you'd get the error your seeing.

If you have no data, just blow away the tables and start again. If you have
data, now is a good time to find out about South (http://south.aeracode.org)

Malcolm


On 21 July 2011 15:34, Schmidtchen Schleicher <spiolli...@googlemail.com>wrote:

> Something went wrong with posting the model, it should be:
>
>
> # -*- coding: utf-8 -*-
> from django.db import models
> from django.contrib.auth.models import User
> import datetime
>
> class Kalender(models.Model):
> name = models.CharField("Kalendername", max_length=100)
> description = models.TextField("Beschreibung")
>
> class Meta:
> verbose_name_plural = "Kalender"
>
> class Termin(models.Model):
> in_calendar = models.ForeignKey(Kalender)
> name = models.CharField("Terminname", max_length=100)
> date = models.DateTimeField("Datum und Uhrzeit")
> description = models.TextField("Beschreibung")
>
> def is_today(self):
> return self.date.date() == datetime.date.today()
>
> is_today.short_description = "Termin findet heute statt?"
>
> participants = models.ManyToManyField(User)
>
> class Meta:
> verbose_name_plural = "Termine"
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/IiaS26VAlVAJ.
>
> 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.
>



-- 
Malcolm Box
malcolm@gmail.com

-- 
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: import django models without runing the server

[Malcolm Box]

On 18 July 2011 15:41, Shawn Milochik  wrote:

> On Mon, Jul 18, 2011 at 10:33 AM, bruno desthuilliers
>  wrote:
> > On Jul 18, 3:33 pm, Alexander Crössmann
> >  wrote:
> >> Hi Malcom,
> >>
> >> I am not sure the management commands are what I want
> >
> > Strange enough, it seems that everyone starts by saying this and ends
> > up writing custom management commands ;)
> >
>
>
> Getting the DJANGO_SETTINGS_MODULE correct is all that's needed. I've
> never created a management command, nor needed to.
>

While it's true you don't *need* to, my experience is it's better to.

Every time I've created a separate script to interact with a Django app, it
has subsequently been broken when I've changed something in the app. Usually
this has gone unnoticed until some inconvenient time.

If you make the script a management command, you have an easy way to build
tests for it right into your app, so that it's impossible (ok, hard) for
changes to break the script without you noticing.

So my advice: if you're actively developing your app, then make any scripts
that need to furtle about with the models management commands.

Malcolm

-- 
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 - can't open image in model save()

[Malcolm Box]

On 18 July 2011 02:04, galgal  wrote:

> def upload_path_handler(instance, filename):
>
> return filename
>
> class SpectacleGallery(models.Model):
>
>  image = models.ImageField(upload_to=upload_path_handler)
>
> def save(self, *args, **kwargs):
>
>  Image.open(self.image)
>
>  super(SpectacleGallery, self).save(*args, **kwargs)
>
>  When I try to open it I get:
>
> IOError at /admin/index/spectacle/1/
> cannot identify image file
>
>
You should be able to pass SpectacleGallery.image to PIL open - I've done
similar things in the path.

What happens when you step through the code - what's the value of
self.image? Is it really a valid image file? Is it where it thinks it is?

Malcolm

-- 
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: import django models without runing the server

[Malcolm Box]

On 18 July 2011 13:34, Alexander Crössmann
wrote:

> Hi,
>
> I want to write a python script that works with django models without
> runing the server. My OS ist Ubuntu 10.10.
>
>
I'd suggest using Django management commands:
https://docs.djangoproject.com/en/1.3//howto/custom-management-commands/

Much easier than doing things manually.


> The settings work fine with testserver and apache but wenn I run the
> that skript I geht the following error:
>
> ImportError: Settings cannot be imported, because environment variable
> DJANGO_SETTINGS_MODULE is undefined.
>
>
You need to set the DJANGO_SETTINGS_MODULE environment variable.

Malcolm

-- 
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: Scaling to 30k requests (malcolm box blog)

[Malcolm Box]

Thanks for the recommendations Cal. I hope this stuff is of use to some
people - let me know if anyone wants to know more.

On 10 July 2011 21:06, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Came across the following blog entries today, for those interested in this
> sort of thing:
>
>
> http://attentionshard.wordpress.com/2011/04/26/scaling-django-to-3-requests-per-second/
>
>
> http://attentionshard.wordpress.com/2011/04/03/scaling-to-30k-two-level-caches/
> Interesting approach. Although you'd have to be careful what context it was
> used in (i.e. if your code is written under the assumption that the caching
> server is atomic).
>

Actually atomicity is preserved for updates, as all updates go to the L2
cache servers (so are as atomic as memcache over multiple servers is). The
main gotcha is that you have to be happy that different servers can have
values that are up to N seconds out of date - but generally that's not too
bad, as it's pretty much the same situation as using a reverse proxy cache.


>
> http://attentionshard.wordpress.com/2011/04/26/scaling-to-30k-tsung/
> Never heard of tsung before, looks pretty nice. Will try it out for sure.
>
>
Can't recommend Tsung highly enough. It Just Works for testing large numbers
of concurrent connections, which is more than I can say for other tools I've
tried (apachebench, JMeter, swarm of bees). There's several companies around
that offer to do high load testing but last time I checked their rates were
sky-high.


> The stack they have used is quite interesting. Although they are using
> Apache w/ mod_wsgi (which tends to be a lot slower than using nginx with
> uwsgi), they still seem to have got some decent performance out of it.


Indeed, it's on the to-do list to try comparing the performance of
Apache/mod_wsgi with nginx/uwsgi, but my gut feel is that the webserver +
WSGI container makes only a marginal difference to the overall site
performance. Of course, I Could Be Wrong.

>
>
> http://attentionshard.wordpress.com/2011/06/21/behind-the-scenes-using-cassandra-acunu-to-power-britains-got-talent/
> Explains a bit of their usage of using Cassandra. Would be interesting to
> see some benchmarks though.
>

What benchmarks would you like to see? We sustained 10K writes/second into a
2 node m1.large cluster if that helps.

Malcolm

-- 
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: 'WSGIRequest' object has no attribute 'update'

[Malcolm Box]

Hi,.

On 11 July 2011 08:29, Phang Mulianto  wrote:

>
>
> return render_to_response(template_name, locals(),
> context_instance=(request))
>

The bug is in this line. render_to_response() takes a dictionary as the
context_instance, but this code just passes the request instance.

You probably meant either:

return render_to_response(template_name, locals(),
context_instance=(request, ))  # Note comma

or

return render_to_response(template_name, locals(),
context_instance={'request':request}))

HTH,

Malcolm

-- 
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: my frist django project Error

[Malcolm Box]

Cal,

You are contributing a lot to the django users group, but this response isnt in 
the best spirit of the group. 

Yes, the op could work out from the traceback what the error was, but we were 
all beginners once. If you compare this post to the how to post FAQ its not too 
bad - at least there's a traceback. 

Telling someone they need to learn more python isn't helpful - tell them that 
theres a setting missing and how the traceback makes that clear. 

Sorry to pull you up on this but the helpfulness of this list is important both 
to me and the health of the django community. 

Malcolm


Sent from my iPhone, please excuse any typos

On 9 Jul 2011, at 21:49, "Cal Leeming [Simplicity Media 
Ltd]" wrote:

> Question, have you ever used Python before?
> 
> If no, then I suggest you learn Python before jumping into Django.
> 
> If yes, then you need to learn more about Python.
> 
> Cal
> 
> On Sat, Jul 9, 2011 at 9:21 PM, morning yao  wrote:
> so ,here is the Error Traceback,i need your help,thanks!
> ___
> Environment:
> 
> 
> Request Method: GET
> Request URL: http://127.0.0.1:8000/
> 
> Django Version: 1.3
> Python Version: 2.7.2
> Installed Applications:
> ['django.contrib.auth',
>  'django.contrib.contenttypes',
>  'django.contrib.sessions',
>  'django.contrib.sites',
>  'django.contrib.messages',
>  'django.contrib.staticfiles',
>  'django.contrib.admin']
> Installed Middleware:
> ('django.middleware.common.CommonMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.contrib.messages.middleware.MessageMiddleware')
> 
> 
> Traceback:
> File "C:\Python27\lib\site-packages\django\core\handlers\base.py" in
> get_response
>  101. request.path_info)
> File "C:\Python27\lib\site-packages\django\core\urlresolvers.py" in
> resolve
>  250. for pattern in self.url_patterns:
> File "C:\Python27\lib\site-packages\django\core\urlresolvers.py" in
> _get_url_patterns
>  279. patterns = getattr(self.urlconf_module, "urlpatterns",
> self.urlconf_module)
> File "C:\Python27\lib\site-packages\django\core\urlresolvers.py" in
> _get_urlconf_module
>  274. self._urlconf_module =
> import_module(self.urlconf_name)
> File "C:\Python27\lib\site-packages\django\utils\importlib.py" in
> import_module
>  35. __import__(name)
> File "C:\Python27\Lib\site-packages\django\dinette\..\dinette\urls.py"
> in 
>  4. from dinette.views import
> LatestTopicsByCategory,LatestRepliesOfTopic
> File "C:\Python27\Lib\site-packages\django\dinette\..\dinette
> \views.py" in 
>  19. from dinette.models import Ftopics ,
> SuperCategory ,Category ,Reply, DinetteUserProfile
> File "C:\Python27\Lib\site-packages\django\dinette\..\dinette
> \models.py" in 
>  18.
> logging.config.fileConfig(settings.LOG_FILE_NAME,defaults=dict(log_path=settings.LOG_FILE_PATH))
> File "C:\Python27\lib\site-packages\django\utils\functional.py" in
> __getattr__
>  277. return getattr(self._wrapped, name)
> 
> Exception Type: AttributeError at /
> Exception Value: 'Settings' object has no attribute 'LOG_FILE_NAME'
> 
> --
> 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.
> 
> 
> -- 
> 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.

-- 
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: Speed of search question

[Malcolm Box]

On 6 July 2011 08:17, Benedict Verheyen  wrote:

>
> I have these models (not really but it's to explain my question :))
>
> class Calendar(models.Model):
>name = models.CharField(max_length=60)
>description = models.TextField(blank=True)
>appointment = models.ManyToManyField(Appointment,
> related_name='appointment_set')
>
> class Appointment(models.Model):
>name = models.CharField(max_length=60)
>description = models.TextField(blank=True)
>owner = models.ForeignKey(User, related_name='owner_set')
>
> If I want to show the Calendars of the logged in user, I would have to
> itterate the calendar objects,
> getting the related appointments and from there the user.
>

I think this should work:

Calendar.objects.filter(appointment__owner = request.user)

Try it and see.

Malcolm

-- 
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: change values in "select list"

[Malcolm Box]

On 6 July 2011 09:48, Geoff Kuenning  wrote:

>
> And in any case, this forum would be greatly improved if the general
> snarkiness herein departed for Antarctica and never returned.
>
>
Hear, hear! (For non-native speakers, that means "I agree").

The Django-users list has always been distinguished by it's helpful,
friendly tone. Recently standards seem to have slipped a bit.

I know there has been a recent rash of extremely poorly-asked questions (see
discussions passim) that might have frayed people's patience, especially
among members who answer a lot of questions.

However, as my mother always said, if you haven't got something nice to say,
say nothing. Ignoring those questions, or gently pointing out off-list how
they can get better answers is much better than posting snarky responses. It
also takes less energy and time, and preserves your emotional health for
more rewarding interactions.

Please can we keep things civil and helpful here - I for one value that too
much to see it go without a fight.

Malcolm

-- 
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: upload file isn't working

[Malcolm Box]

On 24 June 2011 17:36, raj  wrote:

> 



> def upload_view(request):
>user = request.user
>if user.is_authenticated():
>if request.method == 'POST':
>form =upload_form(request.POST, request.FILES, user)
>if form.is_valid():
>file_instance = upload_model()
>saved_file = handle_uploads(request, ['doc'])
> #request.POST.get('title'))
>for f in saved_file:
>setattr(file_instance, f[0])
>file_instance.save()
>return HttpResponseRedirect('/user/update/success/')
>else:
>form = upload_form()
>return render_to_response('/home/oneadmin/webapps/oneadmin/
> oneadmin/templates/oneadmissions/documents.html', {'form':form},
> context_instance = RequestContext(request))
>
> my urls.py file has a url that links to the upload_view. I just cant
> seem to find why the file isn't uploading. Whenever I try to upload
> something, it just refreshes the page and states that the given fields
> are required (even though I entered all the information). Help please.
>
>
It looks to me like form.is_valid() is returning False, so you're seeing the
error messages.
You can debug the cause by putting

import pdb;pdb.set_trace()

just above the "if form.is_valid():" line and then stepping through the
validation code in the debugger.

Malcolm

-- 
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: please recommend a video streaming app/lib

[Malcolm Box]

Adobe video server. It's the de facto standard and you can get access via
amazon ec2 easily.
On Jun 26, 2011 5:31 AM, "akonsu"  wrote:
> hello,
>
> can anyone recommend a library or an application for video streaming
> that can be used in a commercial site that requires good performance
> and scalability? we expect the site to receive a lot of traffic. and
> the main functionality is video on demand.
>
> thank you
>
> --
> 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.
>

-- 
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: mach-o, but wrong architecture

[Malcolm Box]

Re your cacheing problem the behaviour you are seeing is exactly what would be 
expected using locmem cache. 

Apache is presumably running multiple processes each of which will have it's 
own locmem cache. Since the odds ate against two successive requests hitting 
the same apache process, you won't see the data in your cache. 

The simplest fix is to use memcached. 

HTH
Malcolm

Sent from my iPhone, please excuse any typos

On 23 Jun 2011, at 22:00, John  wrote:

> O.K.  I know that there are a lot of suggestions out there for this
> problem, I think I have tried all of them but I am still getting the
> dreaded error in the subject line loading the MySQLdb module.
> 
> Everything was working fine, but I was having problems with a
> LocMemCache so I decided to upgrade from Django 1.2.3 to Django 1.3.
> At the same time I decided to move to Python 2.6 to Python 2.7.  This
> is on Mac SnowLeopard on a MacBook Pro.
> 
> I have tried build and install of the MySQL-python-1.2.3 connector
> using ARCHFLAGS="-arch i386", "-arch -686", "-arch x86-64" and "-arch
> x86-32".  I get the same error in all cases.  I can see that the
> module being loaded is the one that was built and installed in each
> case.
> 
> ALso, since it was mentioned as the reason for moving to Django 1.3,
> does anyone have any suggestions for solving my cache problem?  I am
> trying to save a rather large dictionary of financial calculation
> numbers to a LocMemCache.  In the debug environment it works just fine
> but when I deploy to an Apache http server the cache seems to get
> cleared between each HTTP request.  Via logging I can confirm that the
> object is serialized to the cache and can be immediately retrieved
> form the cache but the object no longer exists when the next HTTP
> request comes in on the same session.
> 
> Thank you for your asistance.
> 
> -- 
> 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.
> 

-- 
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: Possible interest in a webcast/presentation about Django site with 40mil+ rows of data??

[Malcolm Box]

On 22 June 2011 14:15, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Hi all,
>
> Therefore, I'd like to see if there would be any interest in webcast in
> which I would explain how we handle such large amounts of data, the trial
> and error processes we went through, some really neat tricks we've done to
> avoid bottlenecks, our own approach to smart content filtering, and some of
> the valuable lessons we have learned. The webcast would be completely free
> of charge, last a couple of hours (with a short break) and anyone can
> attend. I'd also offer up a Q session at the end.
>
> If you're interested, please reply on-list so others can see.
>

Count me in.

Malcolm

-- 
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: csrf protection and testing with tsung

[Malcolm Box]

On 22 June 2011 09:52, Ivan Uemlianin  wrote:
>
> Thanks very much for your help!  You were exactly right.  The
> following config works (simplified for exposition).

Glad that helped, and thank you for coming back with the working
settings for anyone else who runs into the same problem.

Malcolm

-- 
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: csrf protection and testing with tsung

[Malcolm Box]

On 21 June 2011 16:48, Ivan Uemlianin  wrote:
> With tsung you record a site visit (called a session) --- log in, view
> various pages, do a few things, log out --- and tsung will then hit
> the site with lots of randomised versions of this session.
>

> Many of the views are csrf protected, and the automated requests tsung
> generates don't get through the protection.  For the moment I'm just
> commenting out the csrf middleware in settings.py, but this is
> obviously inconvenient.
>

I think you'll need to do some work with dyn_variable to pull the csrf
token out of the original form and re-inject it into the post you send
back. As far as I understand it, all that the csrf protection is is an
opaque value hidden in any form that needs to be present in the
submitted version to be valid. That stops "loose" posts from CSRF
attacks working as they don't know the magic key.

Malcolm

-- 
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: Strange value_from_object() return value (2L returned instead of unicode string)

[Malcolm Box]

On 21 June 2011 15:47, Jeff Blaine  wrote:

> Okay, here's the problem.
>
> >>> f = dev._meta.get_field('distro')
> >>> f.value_from_object(dev)
> 2L
>
> >>> f.attname
> 'distro_id'
> >>>
>
> As others guessed, value_from_object() is returning the pk ID in this
> case.
>
>
Model "Distro" is the only model of mine showing this behavior, as it is the
> only foreign key "target" model I have defined without named primary key.
>
>
No, I think you're seeing the same behaviour for all fields - ie you're
retrieving the value of the key for the related item. However for the Status
model, that value is a string since you've defined a charfield as the
primary key.

Under the hood, related fields store the key of the related item, not the
item itself. Clever Stuff (TM) in the ORM then reifies those objects as
needed.


Malcolm

-- 
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: Strange value_from_object() return value (2L returned instead of unicode string)

[Malcolm Box]

On 21 Jun 2011, at 01:53, Jeff Blaine wrote:

> >>> from hostdb.models import Device, Interface
> >>> hostname = 'beijing.mitre.org'
> >>> dev = Interface.objects.get(fqdn=hostname).device
> >>> dev.status
> 
> >>> f = dev._meta.get_field('status')
> >>> f.value_from_object(dev)
> u'Online'
> >>> # Super -- this is exactly what I would expect.  Now trouble
> >>> dev.distro
> 
> >>> print dev.distro
> redhat 5.6
> >>> f = dev._meta.get_field('distro')
> >>> f.value_from_object(dev)
> 2L
> >>> # what the hell?

Psychic debugging since you didn't post the Device model:

dev.distro is a foreign key to the Distro model. When you ask for the value via 
the get_field, you actually end up with the PK of the Distro rather than the 
distro instance.

Malcolm

-- 
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: Why does OpenLayers not load in django with this template ?

[Malcolm Box]

On 17 Jun 2011, at 23:07, Satyajit Sarangi wrote:

> 
> This is my template .
>
> 
> Where should I store the OpenLayers-2.10 folder for this template to
> work ?

Almost certainly there is no such place. Assuming your web page is at 
http://example.com/a/path/to/page, you've told it to look for the JS file at 
http://example.com/a/path/OpenLayers.js which is highly unlikely to map to 
something that gets served by your webserver.

You need to read the documentation on media files, and then put the path to 
your media root in the script tag.

Malcolm

-- 
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: Authentication in API (REST)

[Malcolm Box]

I think oauth solves this problem well. What do you see wrong with it?

Malcolm

Sent from my iPhone, please excuse any typos

On 14 Jun 2011, at 16:35, Stuart MacKay  wrote:

> Neznez,
> 
> The authentication problem is one that has never really been solved to any 
> general level of satisfaction for REST APIs, since the connection should be 
> stateless. For HTTP authentication there is either HTTPS + Basic or Digest.  
> HTTPS + Basic considered to be the easiest to implement and the most secure 
> but running a server with SSL is not the most trivial of tasks and there are 
> issues for clients and the problems of managing certificates, etc. etc.
> 
> For a Java based REST API I used the scheme used by Amazon web services where 
> the request is signed using a secret key and then authenticated on the server 
> which worked rather well and was resistant against lots of different types of 
> attack. You can find out more at 
> http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAuthentication.html.
>  However I am not sure what level of support you can find in django.
> 
> Stuart
> 
>> Hi all, I'm newbie in Django, and I started to build my own API. I
>> know that there is Piston or Django REST framework, but I want to
>> learn API from scratch. What I want to know is, how to make my HTTP
>> Response (View) is perform authentication before can be accessed, or
>> we can make it have to throw username and password to access the HTTP
>> Response?
>> 
>> My code is very simple, like this one:
>> def test_api_view(request, whatever):
>>   #
>>   # do things
>>   #
>>   return HttpResponse(serializers.serialize("json", mydictionary),
>> mimetype='application/json')
>> 
>> Thank you.
>> 
> 
> -- 
> 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.
> 

-- 
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: Updating static files: Still in browser cache

[Malcolm Box]

On 10 June 2011 14:54, Thomas Guettler <h...@tbz-pariv.de> wrote:

>  On 09.06.2011 19:18, Malcolm Box wrote:
> > On 9 Jun 2011, at 14:21, DrBloodmoney <drbloodmo...@gmail.com> wrote:
> >
> >> On Thu, Jun 9, 2011 at 9:16 AM, Malcolm Box <malcolm@gmail.com>
> wrote:
> >>> On 9 June 2011 08:09, Thomas Guettler <h...@tbz-pariv.de> wrote:
> which application does not cache URLs with a query string? I think most do,
> or am I wrong?Malcolm Box
>

http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

Squid for one (at least in some configurations). There are no doubt others.

First rule of caching: there will always be a totally borked cache between
you and your users.

Malcolm

-- 
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: Authentication in API (REST)

[Malcolm Box]

On 10 June 2011 01:26, Yohanes Adhi Nugraha  wrote:

>
> Not that one, if we use django.contrib.auth and @login_required,  it's
> only redirects you to login page.
> What I saw from another site is, browser will popup an alert with
> username and password to be filled.
>
>

View source is your friend. Have a look at the other site and figure out how
they do it.

My guess is that they will have an unauthenticated page with some JS on it
that tries to make an authenticated call, catches any return error and
prompts for login.

Malcolm

-- 
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: Authentication in API (REST)

[Malcolm Box]

On 9 June 2011 17:51, Neznez  wrote:

> Hi all, I'm newbie in Django, and I started to build my own API. I
> know that there is Piston or Django REST framework, but I want to
> learn API from scratch. What I want to know is, how to make my HTTP
> Response (View) is perform authentication before can be accessed, or
> we can make it have to throw username and password to access the HTTP
> Response?
>
>
https://docs.djangoproject.com/en/1.3/topics/auth/

Malcolm

-- 
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: Boolean field, unexpected behavior

[Malcolm Box]

On 9 June 2011 21:16, elliot  wrote:

> However, I'm still not clear why i can save without specifying values
> for the CharField or BooleanField.  I didn't say null="true", and I
> didn't provide default values.
>
>
Because both have sensible default values ("" for CharField, False for
BooleanField), and because a Boolean field cannot be null (you need a
NullBooleanField for that).

Malcolm

-- 
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: Updating static files: Still in browser cache

[Malcolm Box]

Sent from my iPhone, please excuse any typos

On 9 Jun 2011, at 14:21, DrBloodmoney <drbloodmo...@gmail.com> wrote:

> On Thu, Jun 9, 2011 at 9:16 AM, Malcolm Box <malcolm@gmail.com> wrote:
>> On 9 June 2011 08:09, Thomas Guettler <h...@tbz-pariv.de> wrote:
>>> 
>>> My static files (JS/CSS) are cached in the browser. But if there is a bug
>>> in a file, an update won't help people which have already cached the old
>>> file.
>>> 
>>> You would need a new URL for every change in the JS/CSS files.
>>> 
>> 
>> Version all static assets, bump the version when you change them.
> 
> I keep the file name the same and append a querystring eg.
> /static/js/mycustom.js?v=1001 then just increment the querystring on
> versioning.

That works but may bust intermediate caches. Some won't cache anything with a 
query string. 

Malcolm

-- 
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: Updating static files: Still in browser cache

[Malcolm Box]

On 9 June 2011 08:09, Thomas Guettler  wrote:

> My static files (JS/CSS) are cached in the browser. But if there is a bug
> in a file, an update won't help people which have already cached the old
> file.
>
> You would need a new URL for every change in the JS/CSS files.
>
>
Version all static assets, bump the version when you change them.

Malcolm

-- 
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 transactions.

[Malcolm Box]

On 8 June 2011 11:07, Marc Aymerich <glicer...@gmail.com> wrote:

> On Tue, Jun 7, 2011 at 11:53 PM, Malcolm Box <malcolm@gmail.com>
> wrote:
> > n 7 June 2011 15:16, Marc Aymerich <glicer...@gmail.com> wrote:You're
> right :) I'm using Mysql with myisam, I'm going to switch to
> InnoDB engine and try again.
>
> I thought that the transaction stuff were implemented in python and
> doesn't relay on DB backend. :(
>
>
As a thought experiment, how did you think that would work? Remember in
production there's a bunch of separate processes running Django - how would
they implement a database transaction?

Malcolm

-- 
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: 2 projects based on the same codebase

[Malcolm Box]

On 9 June 2011 08:06, Benedict Verheyen  wrote:

>
> I developed a calltracking for our team and now, another team is interested
> to have their own calltracking.
> The best way to seem to deal with a project that is the same from the
> start, is to makea new virtualenv
> and "git clone" the codebase. The new project might slightly differ in the
> futur.
>
>
Clone the codebase into a new repository for the new team. Deploy from this
repository to your server, so each team has their own repository deployed
into their own virtualenv.

Then if either side modifies the common code, you can git push/git pull the
changes across between the two root repositories.

You could also consider using git submodules to refer to the "master" copy
of the calltracking module in the second team repository.

Malcolm

-- 
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: Re: Odp: Re: signals pre_save vs model's save()

[Malcolm Box]

On 2 June 2011 23:37, Mateusz Harasymczuk  wrote:

> That was a very good and convincing post :}
> I am testing a solution with .clean(), which IMHO is a better place to
> clean data before save()
>
>
Glad to have been of help.

clean() is ideal for cleaning up stuff from forms, so could be a great fit
for your use case.

Malcolm

-- 
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 transactions.

[Malcolm Box]

n 7 June 2011 15:16, Marc Aymerich  wrote:

> Hi,
> I've activated the
> 'django.middleware.transaction.TransactionMiddleware' and I've
> decorated one method with @transaction.commit_on_success
> With this I expect that if the method raise an exception, django rolls
> back any database operation executed by this method, even the
> operations executed by submethods called by this main method, right?
> So I got this exception but the changes made on the DB during the
> method execution still there.
>
>
What database are you using? Does it support transactions?

Malcolm

-- 
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: Users not logging out

[Malcolm Box]

On 7 June 2011 15:14, Derek  wrote:

> On Jun 7, 3:39 pm, jayhalleaux  wrote:
> > i take that back.
> >
> > If I log in and then I close the tab, I can go back and still use the
> > url to go to a login required page.
>
> close_tab != CLOSE_BROWSER
>
> (An interesting discussion on this type of problem:
>
> http://www.thewebsqueeze.com/forum/PHP-f11/Logout-On-Browser-Close-t5342.html
> )
>
>
The fundamental problem is there is absolutely NO WAY for Django to know
that the user has closed their browser/gone away/been abducted by aliens,
and thus to know they should be logged out.

All else is just work-arounds for this fact:

- Browsers will clear cookies with no expiry time set when the browser exits
(maybe), so SESSION_EXPIRE_AT_BROWSER_
CLOSE uses such a cookie for the Django session cookie, so the browser might
delete it on exit.

- It's possible to add an inactivity timer on the server side, so that if
the user isn't seen for a while the session is expired. How to do this is
left as an exercise to the reader.

HTH,

Malcolm

-- 
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: repr(request.session)

[Malcolm Box]

n 7 June 2011 10:46, Henrik Genssen  wrote:

> I try to add the content of my session to the error-mails.
> I have written a middleware, overwriting the standard error mail.
> But for:
> repr(request.session)
> I only get:
> 
>
> What am I doing wrong?
>
> That is the how a session object displays. Depending what information you
want from the session, you'll need to explicitly extract and format that
into your email.

If you're not sure what you need to print, drop into the debugger in your
middleware and poke around in the request.session object to figure it out.

Do this by putting "import pdb; pdb.set_trace()" in your code  where you're
accessing the session.

Malcolm

-- 
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: Odp: Re: signals pre_save vs model's save()

[Malcolm Box]

On 29 May 2011, at 15:53, Mateusz Harasymczuk wrote:

> W dniu niedziela, 29 maja 2011, 15:36:13 UTC+2 użytkownik Malcolm Box napisał:
> On 28 May 2011 11:05, Mateusz Harasymczuk <mat...@harasymczuk.pl> wrote:
> I am thinking about splitting my model's save() method over few signals.
> 
> For example, stripping spaces and making string capitalized.
> 
> 
> Why would you want to do that?
> 
> Because I am writing CRM, and my end users are non-technical ladies :}
> And each one of them inputs data in different format (id numbers, phone 
> numbers, dates, names [upper cased, capitalized, lower cased])
> Therefore I have to normalize an input to store, and then print contract 
> agreements in normalized way.
> You may say normalize via template tags at rendering level.
> Yes, but I use those data for example to calculate date ranges and text 
> search.
> If someone has an resignation addendum I have to make some other changes to 
> model.
> It is easier to normalize them in pre_save or at the save() method

I understand why you might want to clean up data, or have other processing on 
saving. I have no idea why you'd want to do that using signals rather than 
making things explicit in the model file.

> 
> If this logic is tied to your model, what is the advantage of moving it out 
> of the save() method in your model definition?  
> You would more usefully serve the same purpose by decomposing the save() 
> method into several functions e.g.:
> 
> my largest model is about 20 fields length.
> where save methods are about at least 50 lines long.
> 
> it gives me a mess.
> 

Is your problem that you've got 50 lines of code, or that you've got one 
function that's 50 lines long? If it's the function length that's a problem, 
then split the function up. Functions (including save()) can call other ones.

> and then there are list_display functions (each is 1 to 3 lines long) which 
> almost doubles fields length and gives me a 150-200 lines length model file, 
> with only 20 fileds
> 

If you have a lot of functionality to implement, you will end up with lots of 
lines of code. The art is in keeping the code organised so that you minimise 
the amount of code you have to look at at any one point.

> and I have not included comments and docstrings...
> 
Well you should probably have some of both :)
> 
> 
> Clean, simple and makes it very obvious what you're doing in the save() 
> method. Compare that with the signals version, which will give someone 
> reading the code no clue at all that when they call save() the values of the 
> fields will change.
> 
> I can provide a comment in a model file, that normalize functions are stored 
> in signals file.
>  

If you don't like having the functions in the model file, then move them into a 
separate .py file and import them into the models file. There's no need to use 
signals.


> I am not saying this is a good approach,
> I am thinking this might be a good solution in my case.
> 

Signals are designed to allow you to react to stuff happening in code that's 
unrelated to yours - not to allow you to stick a whole bunch of arbitrary 
processing into the middle of the save() routine for your own models.

> Looking forward to hearing some more opinions.
> I might reconsider, if someone points me a better solution, than I am 
> thinking of.
> 

Here's the right solution

utils.py:

def capitalise():
   

def other_stuff():
   .

models.py

from utils import capitalise, other_stuff,...

class MyModel(..):
 field1 = models.CharField()
def save(self, *args, **kwargs):
self.field1 = capitalise(self.field1)
self.field1 = other_stuff(self.field1)
super(MyModel, self).save(*args, **kwargs)


Except for the explicit calls to the capitalise()/other_stuff() functions in 
the save() method, this code is organised exactly like your proposed signals 
version, but it has the following advantages:

- It makes it explicit what processing is being done to the model on save()
- It makes the *ordering* of processing explicit - signals don't offer that

By all means go down the signals route if you want, it's your code. But you 
will then have two problems: your original one, and using signals.

HTH,

Malcolm

-- 
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: Disable debug logging for django.db.backends?

[Malcolm Box]

Alternatively, configure your logging handlers to send the db logging somewhere 
else (ie another file), and not to pass it on.

So in settings.py have:

LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'file_logging': {
'level' : 'DEBUG',
'class' : 'logging.handlers.RotatingFileHandler',
'backupCount' : 5,
'maxBytes': 500,
'filename': 'django.log'
},
'db_logging': {
'level' : 'DEBUG',
'class' : 'logging.handlers.RotatingFileHandler',
'backupCount' : 5,
'maxBytes': 500,
'filename': 'django-db.log'
},
},

'loggers': {
'django' : {
'handlers': ['file_logging'],
'level' : 'DEBUG',
'propagate' : False,
},
'django.db' : {
'handlers' : ['db_logging'],
'level' : 'DEBUG',
'propagate': False,
},
}

Which should send your db logs just to the django-db.log file.

HTH,

Malcolm

On 30 May 2011, at 18:11, Nathan Duthoit wrote:

> It's more of a hack than a clean solution but it works. Add the
> following to your settings file:
> 
>import logging
>logging.getLogger('django.db.backends').setLevel(logging.ERROR)
> 
> On May 24, 12:32 am, diafygi  wrote:
>> Howdy all,
>> 
>> I have DEBUG=True in my settings.py, and I have several logging
>> entries in my project (Django 1.3)
>> 
>> However, when I am testing, there are tons of django.db.backends debug
>> entries that appear, and my logs gets lost in the shuffle.
>> 
>> Is there a way to disable django.db.backends in my settings.py? What
>> is an example?
>> 
>> Thanks,
>> Daniel
> 
> -- 
> 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.
> 

-- 
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: How to create user on mobile app for Django site?

[Malcolm Box]

On 31 May 2011, at 12:35, Ivo Brodien wrote:

> What is the correct way to do the following:
> 
> 1) Mobile App from which a user can create a user/profile on the Django site
> 2) Allow authenticated users to create on the site and query personalized 
> data from the site
> 
> This is what I guess I have to do:
> 
> 1) Create a REST API  (probably with e.g. django-piston) on at the Django 
> site for creation and authentication 
> 
There's no one correct way, but that way will work well. I've done something 
similar in the past and had mobile clients working across pretty much all phone 
platforms.

> How would I authenticate against the Django site?

Your choices are either to use username/passwords or OAuth. If you're using 
username/passwords you can hook straight into the standard Django 
authentication - just have your code do a POST to /admin/login with 
username/password. That's not massively secure, so you might want to consider 
doing it over SSL.

> When I use URL connections from the mobile app do I always have to send the 
> credentials or can the Django site identify me by storing session cookies on 
> the client just like as if the mobile app would be a browser?
> 
You can use session cookies just as on the desktop - the iPhone NSURLRequest 
will handle cookies for you. This is true on most platforms, the only place 
I've found where it doesn't work consistently is on Flash.

Of course if you choose to do OAuth then you simply sign each authenticated 
request. This works really well if you want to do some authenticated and some 
unauthenticated requests.

Malcolm

-- 
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: signals pre_save vs model's save()

[Malcolm Box]

On 28 May 2011 11:05, Mateusz Harasymczuk  wrote:

> I am thinking about splitting my model's save() method over few signals.
>
> For example, stripping spaces and making string capitalized.
>
>
Why would you want to do that?


> I have even more sophisticated problems such as making an object field
> active set to False basing on various parameters from other fields, such as
> expiration date, or good or bad karma points.
>
> What do you think, it is generally good idea, to keep models file clean out
> of heavily overloaded save() methods?
>
>
If this logic is tied to your model, what is the advantage of moving it out
of the save() method in your model definition?
You would more usefully serve the same purpose by decomposing the save()
method into several functions e.g.:

def save(self,...):
self._strip_chars()
self._validate_and_set_fields()
super(Model, self).save()

Clean, simple and makes it very obvious what you're doing in the save()
method. Compare that with the signals version, which will give someone
reading the code no clue at all that when they call save() the values of the
fields will change.

How about making more than one signal pre_save to the same model?
>
> It will work, but it's the wrong approach.

Malcolm

-- 
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: choice_set.all()

[Malcolm Box]

On 29 May 2011 06:20, bahare hoseini <bhhose...@gmail.com> wrote:

> hi there,
> i followed the structure in
> https://docs.djangoproject.com/en/dev/intro/tutorial01/  ,every thing was
> allright till i wrote the code: >>> "p.choice_set.all()" , then i got
> "AttributeError: 'function' object has no attribute choice_set" . :(
> can somone help?!
>

Psychic debugging: you previously typed:

p = Poll.objects.get
rather than
p = Poll.objects.get(pk=1)

If you did type the former, then p is a method reference and thus you would
get the error above.

Malcolm


>  --
> 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.
>



-- 
Malcolm Box
malcolm@gmail.com

-- 
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: primary key auto increment with PostgreSQL and non Django standard column name

[Malcolm Box]

You need to tell django what the db column name for your pollkey field is. Look 
at the dbname field option in the docs. 


Sent from my iPhone, please excuse any typos

On 28 May 2011, at 05:13, Naoko Reeves  wrote:

> I see if column is set to AutoField then Django won't send INSERT poll_key
> as null.
> Now my problem is that it doesn't return newly assigned primary key value
> for me if primary key name is _key instead of _id
> It looks as if sequence name is not understood correctly.
> Could you tell me if
> 1) I need to change sequence name to something else? Currently it is
> poll_key_seq
> 2) Is there a way to specify the sequence name?
> 
> 
> class Poll(models.Model):
>poll_key = models.AutoField(primary_key=True)
>poll_question = models.CharField(max_length=200, default='')
> 
> class Poll2(models.Model):
>poll2_id = models.AutoField(primary_key=True)
>poll2_question = models.CharField(max_length=200, default='')
> 
 from mysite.polls.models import Poll2
 p3 = Poll2(poll2_question='3')
 p3.save()
 p3.pk
> 2L
 p4 = Poll2(poll2_question='4')
 p4.save()
 p4.pk
> 3L
 from mysite.polls.models import Poll
 p5 = Poll(poll_question='5')
 p5.save()
 print p5.pk
> None
> 
> 
> On 5/27/11 5:31 PM, "Casey Greene"  wrote:
> 
>> Doesn't autofield with primary_key=True handle this for you (instead of
>> making it an IntegerField):
>> 
>> https://docs.djangoproject.com/en/1.3/ref/models/fields/#autofield
>> 
>> Hope this helps!
>> Casey
>> 
>> On 05/27/2011 07:22 PM, Naoko Reeves wrote:
>>> Hi, I have a Django newbie question.
>>> My goal is to auto increment primary key with non Django standard column
>>> name.
>>> We are converting from existing database and primary key schema is
>>> "tablename_key" and not "id".
>>> I googled it and end up reaching to this ticket:
>>> https://code.djangoproject.com/ticket/13295
>>> So I understand that there is work in progress but I wanted find work
>>> around..
>>> 
>>> 1. My first try was to let postgres handle it.
>>> 
>>> my postgreSQL table looks like this:
>>> 
>>> CREATE TABLE poll
>>> (
>>>   poll_key integer NOT NULL DEFAULT nextval('poll_key_seq'::regclass),
>>>   poll_question character varying(200) NOT NULL,
>>>   poll_pub_date timestamp with time zone NOT NULL,
>>>   CONSTRAINT poll_pkey PRIMARY KEY (poll_key)
>>> )
>>> 
>>> My model look like this:
>>> class Poll(models.Model):
>>> poll_key = models.IntegerField(primary_key=True)
>>> poll_question = models.CharField(max_length=200, default='')
>>> poll_pub_date = models.DateTimeField('date published',
>>> default=datetime.date.today())
>>> class Meta:
>>> db_table = u'poll'
>>> 
>>> I was hoping that with this, I could
>>> p = Poll(poll_question="Question 1?")
>>> p.save()
>>> 
>>> but this fails because Django is actually sending the following statement:
>>> INSERT INTO "poll" ("poll_key", "poll_question", "poll_pub_date")
>>> VALUES (NULL, 'Question 1?', NULL)
>>> 
>>> 
>>> 2. My Second attempt is then to add default to model
>>> 
>>> Created a function to return sequence value
>>> from django.db import connection
>>> def c_get_next_key(seq_name):
>>> """ return next value of sequence """
>>> c = connection.cursor()
>>> c.execute("SELECT nextval('%s')" % seq_name)
>>> row = c.fetchone()
>>> return int(row[0])
>>> 
>>> Calling like below works just fine. Everytime I call it, I get new number.
>>> c_get_next_key('poll_key_seq')
>>> 
>>> Then I modify Poll_key in Poll model as follows:
>>> Poll_key = models.IntegerField(primary_key=True,
>>> default=c_get_next_key('poll_key_seq'))
>>> 
>>> I went to Django Shell and created first record.
>>> p1 = Poll(poll_question="P1")
>>> p1.poll_key
>>> # this will return let's say 37
>>> p1.save()
>>> # saves just fine.
>>> 
>>> # instantiating new object
>>> p2 = Poll(poll_question="P2")
>>> p2.poll_key
>>> # this also return 37.
>>> 
>>> I know I must be doing something wrong... but could you pint me to right
>>> direction? I am expecting p2.poll_key to return 38.
>>> Thank you very much for your help in advance.
>>> 
>>> Naoko
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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.
> 
> 
> -- 
> 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.
> 

-- 
You received this message 

Re: caching ajax json (post)

[Malcolm Box]

On 27 May 2011 08:12, Олег Корсак <kamikaze.is.waiting@gmail.com> wrote:

> Hello. Is there a way to cache ajax json responce after post request
> like after get?
> Thanks.
>
> Where do you want to cache it?
Why do you want to cache a POST request? POST should be used to alter the
state of the application - so it's probable that whatever was cached before
is no longer valid.

If you really, really want to do this using Django, it has nothing to do
with AJAX or JSON. Just alter your view function to cache the POST response
and replay it to the next POST. You get to choose what comes back from your
views.

Malcolm



-- 
Malcolm Box
malcolm@gmail.com

-- 
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: Caught RuntimeError while rendering: invalid label:

[Malcolm Box]

On 26 May 2011 20:50, Bobby Roberts  wrote:

> anyone have any idea what invalid label means?
>
>
Where are you getting this error? What did you do to trigger it?

If you can give us more information, it's more likely that someone will be
able to help you.

Malcolm

-- 
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: Admin broken with large data table

[Malcolm Box]

On Mar 29, 4:31 pm, Malcolm Box <malcolm@gmail.com> wrote:
> On Mar 29, 2:48 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>
> > On Tue, Mar 29, 2011 at 5:56 AM, Malcolm Box <malcolm@gmail.com> wrote:
> > > On one of my models, the admin choice_list page is taking minutes to
> > > load, which makes it somewhat broken.
>
> > > The table has about 2M rows and about 2.6GB in size, on InnoDB/MySQL.
> > > As far as I can tell, what's breaking things is the paginator code
> > > that is doing a SELECT COUNT(*) which is known to be glacially slow on
> > > InnoDB with certain types of table.
>
> > Yup, this is a known problem: pagination in the admin isn't efficient
> > and breaks down past a certain point.
>
> OK, thanks. Is there a ticket tracking the problem, I couldn't spot
> one?

Looked some more and found several tickets that relate:

https://code.djangoproject.com/ticket/84088 asks for switching off
count(*)
https://code.djangoproject.com/ticket/4065 asks for disabling
pagination completely.

> > > Is there any way to suppress the pagination and/or change it so that
> > > it doesn't do the queryset.count()?
>
> > In 1.3 you should be able to override ModelAdmin.get_paginator
> > (http://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contri...).
> > You'll have to subclass django.core.paginator.Paginator and provide an
> > interface that doesn't perform COUNTs.
>

It turns out you have to do a bunch more than that - the admin_list,
ChangeList and changelist_view code all make the assumption that
asking a Paginator for the number of items or number of pages is a
valid operation. On a non-counting paginator, that doesn't work.

> > [Yes, this is sorta tricky, and ideally it'd be something Django does
> > for you so if you'll share your code when you figure it out I'll try
> > to work it into the next release.]

I've attached a patch to https://code.djangoproject.com/ticket/8408
which is working for me on big tables where previously the admin
totally broke.

Any feedback on the patch would be welcome - if it looks reasonable
I'll put together the tests and documentation update as well.

Cheers,

Malcolm

-- 
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: Userprofile, signal and admin inline edit.

[Malcolm Box]

On 26 May 2011 10:23, Jani Tiainen  wrote:

> If I extend auth.User with custom profile and add automatic profile
> creation signal it works as expected.
>
> But if I try to add admin inline editor for profile when saving I get
> exception about integration violation.
>
> It happens because admin tries to create second profile for user when
> saving.
>
>
Have your signal handler check whether this is a creation of a user or an
edit. Only create the profile in the first case.

You may also need to check whether the profile already exists before trying
to create - get_or_create() is your friend here.

Malcolm

-- 
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: How do you organize your deployment enviroment

[Malcolm Box]

I'd heartily recommend chef - chef.opscode.com. 

Large library of scripts for almost any package or tool you're likely to want, 
scales out to lots of nodes but can be run in a simple solo mode for small 
deployments. Only downside is it's ruby but mostly you use the configuration 
language so not really a problem. 

I use Chef plus fabric to automate deployments of hundreds of nodes. 

Malcolm

Sent from my iPhone, please excuse any typos

On 23 May 2011, at 08:00, DK  wrote:

> Hi,
> 
> I am having a django project that  is being frequently deployed on clean 
> linux installation. After a few deployments I have noticed that this process 
> is very time consuming for me (every time I am preparing run scripts for 
> everything, configuring cronjobs, paths to log files, etc) but this could be 
> easily automated.
> 
> What are a ready solutions to manage such deployments?
> 
> My typical workflow is:
> 1) install packages on debian/ubuntu via aptitude (like database, etc)
> 2) creating new virtualenv + getting pip
> 3) pip install -r requirements (to setup enviroment)
> 4) fetch django project from code repository
> 5) setup runtime dir (I keep there: run - for pid files, logs, conf - for 
> some config variables or scritps, scripts - some starting srcipts)
> 6) setup crontab jobs 
> 7) setup webserver + django wsgi to be started 
> 
> 
> Sure - I can write some custom made installer for that, but wondering if 
> there is some generic tool for such things.
> 
> PS. I have heard about fabric, but didn't investigate this tool yet. 
> 
> 
> 
> -- 
> 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.

-- 
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: Memcached backend - caching data with infinite timeout

[Malcolm Box]

On 17 May 2011 11:15, Tom Evans <tevans...@googlemail.com> wrote:

> On Tue, May 17, 2011 at 11:03 AM, Malcolm Box <malcolm@gmail.com>
> wrote:
> > That looks like a bug in Django. I suggest you file a ticket.
> >
> > The fix would be to compare timeout to None
> >
>
> A ticket has already been submitted about this. The issue is that
> although memcache allows setting 'infinite' timeouts (its not
> infinite, it just pushes out old data on LRU basis), other backends do
> not.
>
> http://code.djangoproject.com/ticket/9595
>
>
Looking at this ticket, the argument is that this would be inconsistent with
other backends, and that therefore there should be another "special" way to
mean infinite timeout.

However, current behaviour isn't consistent: behaviour on passing 0 as
timeout to cache.set() is:

- filecache - deletes the key (sets expiry to now, so that the key will be
deleted on get)
- memcached - sets the expiry time to the default timeout
- locmem - deletes the key (sets expiry time to now).

Changing the memcached backend to make 0 = infinite cache doesn't strike me
as worse than having memcache have 0 = default timeout, and it means that
the useful memcache behaviour of infinite timeout is available.

I'd propose that the behaviour is modified to:

timeout = None : set default timeout on all backends
timeout = 0 : set "longest possible" expiry on all backends. If people are
already relying on 0 = delete on some backends their code already won't work
on memcache.  Alternatively, if this is felt to be a too-big incompatibility
then simply document 0 as special with backend dependant behaviour (the
current situation), and change memcache behaviour to be infinite timeout.

Cheers,

Malcolm

-- 
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: Memcached backend - caching data with infinite timeout

[Malcolm Box]

That looks like a bug in Django. I suggest you file a ticket. 

The fix would be to compare timeout to None 

Sent from my iPhone, please excuse any typos

On 17 May 2011, at 10:54, Paweł Roman  wrote:

> Python-memcached docstring for set() says this:
> 
> """
> @param time: Tells memcached the time which this value should expire,
> either
> as a delta number of seconds, or an absolute unix time-since-the-epoch
> value. See the memcached protocol docs section "Storage Commands"
> for more info on . We default to 0 == cache forever.
> """
> 
> So it says, zero means forever. But django wrapper class for memcache
> has this line in set():
> 
> timeout = timeout or self.default_timeout
> 
> Which means that it will never accept zero as a value unless I specify
> a default timeout of zero in settings (which I don't want to do,
> because I want to have the default value other than 'forever'), I only
> need infinite timeout in few cases.
> 
> Either python-memcached docstring is wrong (i.e. setting time to zero
> doesnt mean "forever") or django doesnt implement it 100% correctly.
> 
> -- 
> 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.
> 

-- 
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: UTF-8 and files automatically created

[Malcolm Box]

Utf-8 and line endings are orthogonal issues. The problem is not that the files 
are not in utf-8, but that windows and Linux don't agree on what character 
means line-end. 

You will run into problems shipping unmodified windows line endings to a Linux 
box. Luckily the answer is git. This can be configured to automagically do the 
conversions. 

Malcolm

Sent from my iPhone, please excuse any typos

On 13 May 2011, at 23:56, Michael  wrote:

> Hello everybody,
> 
> I am a beginner with Django and I was wondering something about UTF-8.
> As a matter of fact, the files created automatically by Django when
> you create your site and apps are not encoded in UTF-8. So some
> characteres like the end of line are specific to the OS you have been
> creating them.
> 
> Since I created them on Windows, I was wondering what will happen when
> I will deploy my django site on a Linux server since the end of line
> character is different ?
> Wouldn't have been interesting to create all the files in a UTF format
> so that the end of line is the same whatever the OS is ?
> 
> That was just a think.
> 
> Thank you
> Bye.
> Michael
> 
> -- 
> 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.
> 

-- 
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: Problem in Configuring the database

[Malcolm Box]

On 7 May 2011 16:44, rahul raj  wrote:

> After this i wanted to install database.. as mentioned in documentation, i
> did install mysql using YaST in OpenSUSE.. when i typed "mysql" in terminal
> it showed an error -- " Can't connect to local
>  MySQL server through socket '/var/run/mysql/mysql.sock' (2)") "
>
>
Almost certainly Mysql isn't running.  Try 'ps aux | grep mysql' and see if
there's anything listed (except for the grep command).

If there's nothing, then 'sudo /etc/init.d/mysqld start' will probably get
you going.

Malcolm


>
>

-- 
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.

ANN: Two-level caching for Django

[Malcolm Box]

Hi,

We recently hit a bottleneck accessing a memcached server from Django on a
big site. To solve it, I created two-level cache with a local cache on each
Django box, and a global cache on the memcached machines.

Under the sort of loads we were seeing, this dramatically reduced the load
on the memcached servers. Best of all, it's a one line change to existing
code using Django's cache framework.

I've released the code here: https://gist.github.com/953524 in case it's
useful to anyone else. Some more background here:
http://attentionshard.wordpress.com/2011/04/03/scaling-to-30k-two-level-caches/

Hope this helps someone.

Cheers,

Malcolm

-- 
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: Admin broken with large data table

[Malcolm Box]

On Mar 29, 2:48 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Tue, Mar 29, 2011 at 5:56 AM, Malcolm Box <malcolm@gmail.com> wrote:
> > On one of my models, the admin choice_list page is taking minutes to
> > load, which makes it somewhat broken.
>
> > The table has about 2M rows and about 2.6GB in size, on InnoDB/MySQL.
> > As far as I can tell, what's breaking things is the paginator code
> > that is doing a SELECT COUNT(*) which is known to be glacially slow on
> > InnoDB with certain types of table.
>
> Yup, this is a known problem: pagination in the admin isn't efficient
> and breaks down past a certain point.
>

OK, thanks. Is there a ticket tracking the problem, I couldn't spot
one?

> > Is there any way to suppress the pagination and/or change it so that
> > it doesn't do the queryset.count()?
>
> In 1.3 you should be able to override ModelAdmin.get_paginator
> (http://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contri...).
> You'll have to subclass django.core.paginator.Paginator and provide an
> interface that doesn't perform COUNTs.
>
> [Yes, this is sorta tricky, and ideally it'd be something Django does
> for you so if you'll share your code when you figure it out I'll try
> to work it into the next release.]

I'll have a look and see what I can come up with. I'll be happy to
share once it's done.

Malcolm

-- 
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: Help on setting TIME_ZONE to 'UTC'

[Malcolm Box]

Look in the docs here: 
http://docs.djangoproject.com/en/1.3/ref/settings/#time-zone

As it says, this doesn't work on Window and will result in the system
timezone being used.

On Mar 29, 8:58 am, aa bb  wrote:
> Hi all! I'm a Django newbie. I set TIME_ZONE to 'UTC' in my project
> settings.py. Then I have defined a data model like:
>
> class D(models.Model):
>   #some fields
>   joined_at = models.DateTimeField(null = True, auto_now_add = True)
>   #some other fields
>
> I expect when a new D instance is created, its joined_at field will be
> a value equivalent to datetime.utcnow(), becuase I set TIME_ZONE to
> 'UTC'. But, when I tested it on Windows, I found that it's in fact
> datetime.now()! I looked for a while for the reason but nothing
> valueble. So please give me a hand if you can. Doesn't UTC time zone
> work in Django? Thanks in advance!

-- 
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.

Admin broken with large data table

[Malcolm Box]

Hi,

On one of my models, the admin choice_list page is taking minutes to
load, which makes it somewhat broken.

The table has about 2M rows and about 2.6GB in size, on InnoDB/MySQL.
As far as I can tell, what's breaking things is the paginator code
that is doing a SELECT COUNT(*) which is known to be glacially slow on
InnoDB with certain types of table.

Is there any way to suppress the pagination and/or change it so that
it doesn't do the queryset.count()?

I've tried adding a separate index on the primary key as suggested
here: http://forums.mysql.com/read.php?22,90945,91110#msg-91110 which
improves things - from > 10 minutes to 134s - but not enough.

It seems this should bite anyone using admin with large tables on
InnoDB or Postgres, so perhaps this is a bug?

Cheers,

Malcolm

-- 
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: Error installing permissions superuser when a userprofile has been defined

[Malcolm Box]

Further investigation: looks like it's a South/syncdb interaction. The
UserProfile will be created by the south migration, but of course that
hasn't run when the auth post_install runs to prompt for a superuser.

Sadly syncdb --migrate doesn't do the right thing either.

For now, I'm just creating a superuser manually using ./manage.py
shell, but would welcome any ideas on how to solve this better.

Malcolm

On Mar 23, 10:11 am, Malcolm Box <malcolm@gmail.com> wrote:
> Hi,
>
> I'm running into an error when doing a syncb on a clean DB during the
> installation of the auth system.
>
> I get the normal prompt "You just installed Django's auth system,
> which means you don't have any superusers defined.  Would you like to
> create one now? (yes/no):" and answer yes.
>
> But when the user is created, I get a django.db.utils.DatabaseError:
> (1146, "Table 'x.x_userprofile' doesn't exist"), because the
> userprofile table from my app hasn't been created yet.
>
> This must be a common problem, but I can't find a recommendation on
> how to deal with it.  What's the right thing to do?
>
> Thanks,
>
> Malcolm

-- 
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.

Error installing permissions superuser when a userprofile has been defined

[Malcolm Box]

Hi,

I'm running into an error when doing a syncb on a clean DB during the
installation of the auth system.

I get the normal prompt "You just installed Django's auth system,
which means you don't have any superusers defined.  Would you like to
create one now? (yes/no):" and answer yes.

But when the user is created, I get a django.db.utils.DatabaseError:
(1146, "Table 'x.x_userprofile' doesn't exist"), because the
userprofile table from my app hasn't been created yet.

This must be a common problem, but I can't find a recommendation on
how to deal with it.  What's the right thing to do?

Thanks,

Malcolm

-- 
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: Weird inconsistencies for same queryset in different Django instances

[Malcolm Box]

On Tue, May 11, 2010 at 8:27 PM, Daniel Roseman <dan...@roseman.org.uk>wrote:

> On May 11, 7:08 pm, Malcolm Box <malcolm@gmail.com> wrote:
> > Hi,
> >
> > I've run into a weird bug that has me scratching my head - I'm seeing
> > inconsistent results from a queryset between various apache processes and
> > the django shell.  I.e. sometimes a GET gives me the right response (as
> it
> > hits a "correct" Apache instance) and other times it gives a wrong
> > response.  Restarting Apache causes problem to go away, but it resurfaces
> > later.
> >
> > I have a Poll class which has a start_time and an end_time, both of which
> > are optional, plus an enabled field.  A poll is considered active if it's
> > enabled, and if it has a start_time then now > start_time, and if it has
> an
> > end_time then now < end_time.
> >
> > What I'm seeing is that sometimes polls with a start_time that is before
> now
> > are not showing up in the responses when I do a series of GETs.  So e.g.
> > first GET - shows poll, second one - doesn't show, third - doesn't,
> fourth -
> > does and so on.
> >
> > From a fresh python shell, the Poll.objects.active() call always gives
> the
> > right results.
> >
> > The code in question is:
> >
> > class PollManager(models.Manager):
> > def active(self):
> > qs = super(PollManager,
> self).get_query_set().filter(enabled=True)
> > q_start = Q(start_time__isnull=True) |
> > Q(start_time__lte=datetime.datetime.now())
> > q_end = Q(end_time__isnull=True) |
> > Q(end_time__gte=datetime.datetime.now())
> > return qs.filter(q_start,q_end)
> >
> > Where the models are is:
> >
> > class Event(models.Model):
> >enabled = models.BooleanField() # automatic default false
> > other fields
> >
> > class Poll(models.Model):
> > event = models.ForeignKey(Event, db_index=True)
> > enabled = models.BooleanField() # automatic default false
> > start_time = models.DateTimeField(blank=True, null=True,
> help_text="Time
> > to enable this poll (optional)")
> > end_time = models.DateTimeField(blank=True, null=True,
> help_text="Time
> > to close this poll (optional)")
> >
> > objects = PollManager()
> >
> > The view logic is basically:
> >
> > def view_polls(request, event_id):
> > filtered_set =  self.queryset._clone()# Queryset is
> > Poll.objects.active().filter(event__enabled = True)
> > filtered_set = filtered_set.filter(event__id=event_id)
> > return render_to_response(template, filtered_set)
> >
> > (this has been elided and adapted - original code is using
> django-rest-api,
> > JSON responder etc.  But the call boils down to this)
> >
> > I'm confused as to what the problem could be - any clues?
> >
> > Cheers,
> >
> > Malcolm
>
> I'd like to see how the queryset is assigned to `self`. My suspicion
> would be that the arguments are being preserved across requests - when
> it's first instantiated, it correctly uses the current time to filter,
> but on subsequent calls it is still using the time as of the first
> request.
>

The queryset is being initialised in the construction of a callable which is
then used for the view.  So yes, it probably is only being initialised once
on server startup.

Thank you!  Still testing the fix, but I think this will fix it.

Cheers,

Malcolm

-- 
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.

Weird inconsistencies for same queryset in different Django instances

[Malcolm Box]

Hi,

I've run into a weird bug that has me scratching my head - I'm seeing
inconsistent results from a queryset between various apache processes and
the django shell.  I.e. sometimes a GET gives me the right response (as it
hits a "correct" Apache instance) and other times it gives a wrong
response.  Restarting Apache causes problem to go away, but it resurfaces
later.

I have a Poll class which has a start_time and an end_time, both of which
are optional, plus an enabled field.  A poll is considered active if it's
enabled, and if it has a start_time then now > start_time, and if it has an
end_time then now < end_time.

What I'm seeing is that sometimes polls with a start_time that is before now
are not showing up in the responses when I do a series of GETs.  So e.g.
first GET - shows poll, second one - doesn't show, third - doesn't, fourth -
does and so on.

>From a fresh python shell, the Poll.objects.active() call always gives the
right results.

The code in question is:

class PollManager(models.Manager):
def active(self):
qs = super(PollManager, self).get_query_set().filter(enabled=True)
q_start = Q(start_time__isnull=True) |
Q(start_time__lte=datetime.datetime.now())
q_end = Q(end_time__isnull=True) |
Q(end_time__gte=datetime.datetime.now())
return qs.filter(q_start,q_end)


Where the models are is:

class Event(models.Model):
   enabled = models.BooleanField() # automatic default false
    other fields

class Poll(models.Model):
event = models.ForeignKey(Event, db_index=True)
enabled = models.BooleanField() # automatic default false
start_time = models.DateTimeField(blank=True, null=True, help_text="Time
to enable this poll (optional)")
end_time = models.DateTimeField(blank=True, null=True, help_text="Time
to close this poll (optional)")

objects = PollManager()


The view logic is basically:

def view_polls(request, event_id):
filtered_set =  self.queryset._clone()# Queryset is
Poll.objects.active().filter(event__enabled = True)
filtered_set = filtered_set.filter(event__id=event_id)
return render_to_response(template, filtered_set)

(this has been elided and adapted - original code is using django-rest-api,
JSON responder etc.  But the call boils down to this)

I'm confused as to what the problem could be - any clues?

Cheers,

Malcolm

-- 
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: Forcing HTTPS in admin

[Malcolm Box]

You could, but doing it on the front-end webserver makes more sense.

Malcolm

On Mon, Mar 1, 2010 at 3:02 PM, ozgurv  wrote:

> You can write a middleware that redirects users who visit admin
> related pages (starts with /admin maybe) to HTTPS.
>
> On Mon, Mar 1, 2010 at 2:08 AM, Janusz Harkot 
> wrote:
> > no, but you can do this very easy on the fronted-webserver (nginx,
> > apache, cherokee etc.)
> >
> > J.
> >
> > --
> > 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.
> >
> >
>
>
>
> --
> Özgür Vatansever
>
> --
> 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.

Re: Django REST and FILEFIELD field

[Malcolm Box]

I've got this working in the past, but only by writing custom create()
methods on the Collection and Entry classes.

In the custom create() method you can process the POST/PUT data directly
into the FileField just like you would for a normal form

Malcolm

On Thu, Feb 25, 2010 at 7:03 PM, manu.polline wrote:

> Hi everyone,
> anyone help me??
>
> On 22 Feb, 19:19, "manu.polline"  wrote:
> > Hi everyone,
> > my name is Manuel. I'm tryng to upload a file directly in a filefield
> > of Django model exposed by django-rest-interface.
> > It'is possible?
> > this is my model :
> >
> > class File(models.Model):
> > file = models.FileField(upload_to='files',
> > help_text=_("file itself"))
> > page = models.ForeignKey(page)
> >
> > and my urls.py :
> > json_File_resource = Collection(
> > queryset = File.objects.all(),
> > authentication = HttpBasicAuthentication(),
> > permitted_methods = ('GET', 'POST', 'PUT', 'DELETE'),
> > receiver = JSONReceiver(),
> > responder = JSONResponder()
> > )
> >
> > urlpatterns = patterns('',
> > 
> > 
> > url(r'^json/File/(.*?)/?$',json_File_resource),
> > ...
> > )
> >
> > The GET works and the PUT to other field too but not the POST or the
> > PUT on filefield Field.
> > How i can pass the local file to the remote Service in the JSON
> > string?
> >
> > Please Help Me!!!
> >
> > Manuel
>
> --
> 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.

Re: fixtures getting created with terminal message prefixed

[Malcolm Box]

I'll take a guess:  one of your apps, middleware or possibly even a
management command is generating this text.

Grep for it in your source code, and remove/disable.

Malcolm

On Sat, Feb 27, 2010 at 4:34 AM, Russell Keith-Magee  wrote:

> On Sat, Feb 27, 2010 at 4:07 AM, Joel Stransky 
> wrote:
> > When ever I create a fixture via dumpdata, I get this text prior to the
> > start of the data.
> >
> > Please select your server identifier.
> >1) admin
> >2) aws
> >3) dipsy
> >4) dot
> >5) local
> >6) sdeng
> >7) soup
> >8) tomcatdev
> >9) www
> > What server identifier would you like to use? []
> >
> > So if I run:
> > manage.py dumpdata > path/to/my/fixtures/myFixture.json
> >
> > I have to open the file and delete that text before I can run:
> > manage.py loaddata myFixture.
> >
> > Anything I can do to prevent that text from getting saved into my
> fixture?
>
> To the best of my knowledge, this isn't text that is produced by
> Django. I can't even think what might be generating this text. Without
> knowing the cause, there isn't much we can do to help.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.

Re: ImageField admin preview not working

[Malcolm Box]

Read your settings.py file carefully:

- you've said that the MEDIA_URL is /
- but that Django is only configured to serve static content from /static

So when the photo is uploaded, it's stored in /photos/x.jpg,
which you've told Django is accessible via the URL /photos.

But this gives http://example.com/photos

And, as per the error message, Django can't find a matching url pattern for
that.

Cheers,

Malcolm

On Sun, Feb 28, 2010 at 5:57 PM, lockwooddev  wrote:

> Hi people,
>
> I started working on an image gallery with Django and I'm stuck. I
> suppose that my static files on the development server are not
> configured properly.
>
> I have the following models.py code:
>
> from django.db import models
> from PIL import Image
>
>
> class Photo(models.Model):
>name = models.CharField(max_length=100)
>description = models.TextField()
>image = models.ImageField(upload_to='photos')
>
>
> 
>
> My setting.py file:
>
>
> MEDIA_ROOT = '/Users/lockwood/Django-1.1.1/md/static_media/'
> MEDIA_URL = '/'
> ADMIN_MEDIA_PREFIX = '/media/'
>
>
> 
>
> And url.py file:
>
> urlpatterns = patterns('',
>(r'^admin/', include(admin.site.urls)),
>(r'^static/(?P.*)$', 'django.views.static.serve',
>{'document_root': settings.MEDIA_ROOT}),
> )
>
>
> 
>
> When I click on the Photo object in the admin view to preview the
> image i've uploaded, I get the following 404 page:
>
>
> Page not found (404)
> Request Method: GET
> Request URL:
> http://127.0.0.1:8000/photos/1459049280_144e7d874a_o-at-2008-12-06.jpg
>
> Using the URLconf defined in md.urls, Django tried these URL patterns,
> in this order:
>
>   1. ^admin/
>   2. ^static/(?P.*)$
>
> The current URL, photos/1459049280_144e7d874a_o-at-2008-12-06.jpg,
> didn't match any of these.
>
> 
>
> The photo's are stored in the absolute path:
>
> /Users/lockwood/Django-1.1.1/md/static_media/photos/
>
> 
>
> I've tried everything and don't know what to do now?
>
> --
> 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.

Re: How can I apply ordering through a M2M join model?

[Malcolm Box]

I don't know if you can do it directly using the ordering metadata - easiest
way to find out is to try it and see.

If not, I'd suggest a customer manager on the Gallery that returns the
photos in order so that the line:

Gallery.photos.all()

refers to your customer manager that "does the right thing".

Custom managers are really easy and very useful - see
http://docs.djangoproject.com/en/dev/topics/db/managers/

Malcolm

On Sun, Feb 28, 2010 at 5:07 PM, Kyle Fox  wrote:

> The user needs to be able to manually position the photos in the
> gallery (using drag and drop, for example).  A photo can exist in
> multiple galleries, which is why the join model GalleryPhoto is
> required (and this is where the position gets stored).
>
> On Feb 27, 7:36 pm, Prabhu  wrote:
> > What is wrong with gallery.photos.all().order_by('name') ?
> >
> > On Feb 27, 4:49 pm, Kyle Fox  wrote:
> >
> >
> >
> > > I'm wondering if it's possible to apply ordering to a ManyToMany
> > > relationship by using a `position` attribute on the join model.  A
> > > classic example (photo gallery) is probably the best way to illustrate
> > > this:
> >
> > > class Photo(models.Model):
> > > image = models.ImageField(upload_to="photos")
> >
> > > class Gallery(models.Model):
> > > name = models.CharField(max_length=100)
> > > photos = models.ManyToManyField(Photo, through='GalleryPhoto')
> >
> > > class GalleryPhoto(models.Model):
> > > gallery = models.ForeignKey(Gallery)
> > > photo = models.ForeignKey(Photo)
> > > position = models.IntegerField(default=0)
> >
> > > class Meta:
> > > ordering = ('position',)
> >
> > > (Also athttp://dpaste.com/hold/165618/)
> >
> > > I want to attach photos with a gallery, like this:
> >
> > > >>> GalleryPhoto.objects.create(photo=photo1, gallery=some_gallery,
> position=1)
> > > >>> GalleryPhoto.objects.create(photo=photo2, gallery=some_gallery,
> position=2)
> >
> > > And then have the photos retrievable through the gallery *according to
> > > the position attribute* on the GalleryPhoto, like so:
> >
> > > >>> gallery.photos.all()
> >
> > > [photo1, photo2]
> >
> > > The simplest fix would be to add create a `get_photos` method on the
> > > Gallery which does a query for it's photos, but I'd rather stick to
> > > straight Django models if at all possible.
> >
> > > Thanks!
>
> --
> 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.

Re: Django with Jquery

[Malcolm Box]

On Sun, Feb 28, 2010 at 5:39 PM, Alexis Selves wrote:

> Hello,
> I am totally helpless. I am trying to use JQuery in my django
> templates, but I always get in firebug this: $ not defined.
>

Check with Firebug if the jquery script has been successfully loaded (using
either the CSS or Net tabs)


> In my template I am linking jquery :
> 
>

Are you sure this file is being correctly loaded in the browser?  Is this
line showing up in the generated HTML?


>
> But  I always get nothing..
> using ubuntu 9.10. Thanks for your help in advance.
>
>
You don't get nothing, you get something that's just not what you expect.
It's much easier to help you debug if you tell us what you do get, and what
steps you've taken to eliminate possibly sources of errors.

For example, in you situation I would check (and report on):

- whether the browser can load the page
- whether the  tag shows up in the browser (use "View Source" or
Firebug)
- whether you can download the JQuery file manually at the location in the
link
- whether the JQuery really was downloaded in the page (check using Firebug)

If all those tests were passed successfully then you've got a very different
problem than if e.g. the browser can't load the page.

Hope this helps.

Malcolm

-- 
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: simple, input from user and database earch result

[Malcolm Box]

On Wed, Feb 17, 2010 at 3:12 PM, gintare  wrote:

>
> One more simple question:
>
> Is it possible that area which is used for data submission also can be
> updated from python script.
>

It's not clear what you mean by this.  The python (Django) script isn't
running in the webbrowser, so it can't update the webbrowser unless the
browser makes a HTTP request and then renders the response.


>  1 2   
>
> On line 1 user put a word
> On line 2 user start search in database
> I would like to get the result of the search printed back in the same
> field on the line 1.
>
> The have the view that the form posts back to put the result of the search
in the generated HTML for the result.

Malcolm

-- 
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: update with where clause constraints?

[Malcolm Box]

2010/2/5 Jared Smith 

> My use case is that I'll have multiple users trying to update a set of
> objects and I want to make sure that any user committing a change has
> knowledge of the existing state.  I was going to model that with a version
> number so an update would look like:
>

Maybe I'm missing something, but this sounds like the canonical use of
ETags.  Provide an Etag with the read, then when the update comes in check
if the ETag matches what is calculated for the current state of the DB.

If it does, let the update through.  If not, then force the user to retry
based on the new state.

Cheers,

Malcolm

-- 
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: Problem with Last-modified header and Apache/mod_python

[Malcolm Box]

Answering my own question in case anyone else runs into this:

The problem was caused by the last_modified field in the database being
empty for existing assets (the last_modified stuff was added later to the
model).

When the last_modified database field is 0, then Django doesn't send a
Last-Modified header based on the value from the database.  Equally it
doesn't produce any error either.

The fix is simple - run some SQL to set all the last_modified fields to a
recent date.  Voila, the header appears.

Hope this proves useful to someone in the future.

Cheers,

Malcolm

2010/2/2 Malcolm Box <malcolm@gmail.com>

> Hi,
>
> I'm seeing a strange problem with Last-modified headers on my
> Apache/mod_python install.  The problem being that they don't get sent.
>
> Running my django app locally, and using 'curl -v' to see the headers, I
> see correctly generated 'Last-modified' headers.
>
> When I deploy the same code to a server running Apache with mod_python, and
> make the same request using curl, there's no sign of a Last-modified header
> coming down.
>
> I'm using the standard last_modified decorators on the view:
>
> from django.views.decorators.http import last_modified
>
> json_skin_scalable =
> last_modified(scalable_last_modified)(SkinScalableCollection(
> queryset=Skin.objects.all(),
> permitted_methods=('GET', 'PUT', 'POST', 'DELETE'),
> anonymous_methods = ('GET',),
> entry_class = SkinScalableEntry,
> responder = JSONResponder(),
> expose_fields = ['base_url','qboxtext', 'softkey', 'link',
> 'swing_options',
>  'swing_results', 'polls_list_off',
> 'polls_list_on',
>  'multi_item_off', 'multi_item_on'
>  ],
> ))
>
> Is there anything special that needs to be done to get Apache to send these
> headers correctly?
>
> Cheers,
>
> Malcolm
>

-- 
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: Speeding the code-test-debug cycle

[Malcolm Box]

Hi,

Thanks for the suggestions.

2010/2/2 Phlip <phlip2...@gmail.com>

> Malcolm Box wrote:
>
> > Has anyone got any ideas on how to speed this up - for instance, is there
> a
> > way to say "use an existing test database"?
>
> Per my other advice to use fab and a fabfile with a test() target in
> it, you should set its (local()) target to something like
>
> OK, I need to have a look at fab to see what it can do for me.  I suspect
it won't solve the slow tests problem though - that seems to be a Django
issue.


> Do not use production fixtures for test fixtures, and if you must use
> the spew of dumpdata for fixtures you should manually trim them down
> to the minimum needed. Name them different from production fixtures.
> We have, naturally, a "countries.json", for all the regions we are
> allowed to sell to, and it takes forever to load. I pushed all our
> tests to use "sample_countries.json", instead, containing only
> countries that Sarah Palin could name on the spot. This made our tests
> much faster.
>
>
Nope, not using production data for fixtures.  Most of my fixtures contain a
handful of objects at most.


> And, finally, your test_settings.py file should use a sqlite3, in-
> memory database:
>
>
That would be wonderful, except my code doesn't run on sqlite3 as it relies
on some extra sql that sqlite doesn't support.


> From there, I have only been able to reduce test time down from hours
> to minutes. Tests ought to run in seconds - so fast that you can run
> them after every few edits - TDD.


Totally agree, and what I'm looking to make Django do.  At the moment a full
test run for my stuff takes about 5 minutes - not impossibly long, but long
enough for a task switch to something else.


> One
> of Django's particular sins is it drags all the data from your JSON
> fixtures into fully resolved models.py objects before saving them.
> This runs tons of Python code for no reason - you are not testing your
> models' validations or save routines. The test runner should instead
> push the JSON contents directly into the database as bulk import
> statements.
>
>
 Hmm, that sounds like something that could be fixed.  Does anyone know if
this is on the Django dev's radar and/or if someone's working on it?

Cheers,

Malcolm

-- 
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.

Speeding the code-test-debug cycle

[Malcolm Box]

Hi,

As my django application has grown I'm noticing I'm spending longer and
longer waiting for ./manage.py test to start up - ie create all the tables
etc.  Not helped of course by working on a laptop with a slow disk, as I
suspect many of us do these days.

This is slowing down my test-debug cycle quite noticably - e.g. when an
import fails due to an typo, the fix is extremely quick but then I have to
wait for ./manage.py test to crank through creating the databases again
before I can find the next bug.

Has anyone got any ideas on how to speed this up - for instance, is there a
way to say "use an existing test database"?

Cheers,

Malcolm

-- 
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.

Problem with Last-modified header and Apache/mod_python

[Malcolm Box]

Hi,

I'm seeing a strange problem with Last-modified headers on my
Apache/mod_python install.  The problem being that they don't get sent.

Running my django app locally, and using 'curl -v' to see the headers, I see
correctly generated 'Last-modified' headers.

When I deploy the same code to a server running Apache with mod_python, and
make the same request using curl, there's no sign of a Last-modified header
coming down.

I'm using the standard last_modified decorators on the view:

from django.views.decorators.http import last_modified

json_skin_scalable =
last_modified(scalable_last_modified)(SkinScalableCollection(
queryset=Skin.objects.all(),
permitted_methods=('GET', 'PUT', 'POST', 'DELETE'),
anonymous_methods = ('GET',),
entry_class = SkinScalableEntry,
responder = JSONResponder(),
expose_fields = ['base_url','qboxtext', 'softkey', 'link',
'swing_options',
 'swing_results', 'polls_list_off', 'polls_list_on',
 'multi_item_off', 'multi_item_on'
 ],
))

Is there anything special that needs to be done to get Apache to send these
headers correctly?

Cheers,

Malcolm

-- 
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: REST & Django

[Malcolm Box]

On Fri, Jan 29, 2010 at 4:03 PM, pyleaf  wrote:

> how REST looks like in django?
> does Django support REST defautly?
>
>
Django can be used to develop a REST API, it implements all the HTTP methods
needed and Django views can easily generate JSON, XML or whatever you
require.

There's not much built-in infrastructure for REST, but add-ons like
django-rest-interface (http://code.google.com/p/django-rest-interface/) do
provide a lot of the boilerplate code.

Malcolm

-- 
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.

Making a model field have a default value

[Malcolm Box]

Hi,

A question that's probably obvious but I can't quite see the best way to do
it.

I've got a model, call it Template, with some fields colour1, colour2 etc.
What I want is that if there's a no value for the colourN field then a
default value is returned when the field is read.

Aha I hear you say, just use

class Template(models.Model):
  colour1 = models.CharField(default = "red")

However, as far as I can tell this only fills in a default value when the
object is first created.  I've got two problems with that:

1) these are new fields on the model, and I've got a whole pile of existing
records where these are going to be blank.  Setting default="red" in the
model doesn't seem to fix that.
2) I do want people to be able to set a colour in the admin, change their
minds, set it to blank and have the original colour restored.

Boiling it down, I want a way to make the colour1 field work like this:

def _get_colour1(self):
if self.value == '':
 return self.default_value
else:
 return self.value

I can't spot an obvious way to do this  - what have I missed?

Thanks,

Malcolm

-- 
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: Reasons why syncdb ignores an application?

[Malcolm Box]

On Wed, Jan 27, 2010 at 6:54 PM, phoebebright wrote:

> I cannot find the reason why syncdb will not create tables from a
> models.py.
>
> It is quite happy to create the auth tables and ones from an external
> app that is included in INSTALLED_APPS but it won't build the tables
> from my 'web' folder.
>
> I can put a print statement in the web.models.py and it appears.  It
> is clearly parsing all the models, because if I put a foreignkey to a
> model which doesn't exist, it complains until I fix the error, but it
> won't build the tables.  I do a syncdb and nothing happens and nothing
> is displayed.
>



> Have included 'from web.models import *' in urls.py and admin.py for
> luck.
>
> This would explain the print statement appearing.


> Have tried copying the web folder to another name and putting that
> name in the INSTALLED_APPS.
>
> The only other symptom is that if I do  'python manage.py sql web'  I
> get the error
> Error: App with label web could not be found. Are you sure your
> INSTALLED_APPS setting is correct?
>
>
What is your python path?  Do manage.py shell
>>> import sys
>>> sys.path

Then try
>>> import web

My guess is that for some reason your python path doesn't include the web
directory.

The only other thing I can think of is some import error in your app that's
silently failing on syncdb - the "import web" test above should spot that.

Cheers,

Malcolm

-- 
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.