Weird inconsistencies for same queryset in different Django instances
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: Weird inconsistencies for same queryset in different Django instances
On Tue, May 11, 2010 at 8:27 PM, Daniel Roseman wrote: > On May 11, 7:08 pm, Malcolm Box 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.
Django performance on Amazon EC2
Hi, I'm using Django on Amazon EC2 and seeing what I think are very low throughputs ( < 15requests/s) for relatively simple pages. Before I start digging into the root causes of this, I wondered if anyone else was running Django on AWS and what sort of performance figures you were seeing. More details on my setup: Ubuntu Hardy Apache 2 Django 1.1 EC2 m1.small instance, talking to another m1.small instance hosting MySQL db DB performance doesn't seem to be the issue - I don't see the DB server under any load at all. 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: Django performance on Amazon EC2
On Tue, Jan 12, 2010 at 2:46 PM, Steve McConville < mcconville.st...@gmail.com> wrote: > > EC2 m1.small instance, talking to another m1.small instance hosting MySQL > db > > > > DB performance doesn't seem to be the issue - I don't see the DB server > > under any load at all. > > What sort of network latencies are you seeing? Are they hosted in > US-East-1? > > Yes, hosted in US-East-1, but I was running benchmark tests from another EC2 instance in the same region, so reasonably sure it's not latency. 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: Django performance on Amazon EC2
On Tue, Jan 12, 2010 at 2:54 PM, Victor Loureiro Lima < victorloureirol...@gmail.com> wrote: > Hello, > > we currently have a website running on django EC2, and its running great, > really great. We managed to handle 300 requests/s on our stress tests on a > heavy page... but, we only managed to get that after we used the django's > cache systems, before that we were running close to 10 requests/s and the > server repeatedly stopped responding. > Is that on m1.small or a larger instance? > In fact we were also getting these requests ( normaly 10 requests/s ) on > our development environment under stress, so Im confortable to say that > thats not an amazon EC2 issue, and that it could be directly related to > django. What requests/second do you guys get on normal django setup? > On a very old iMac with local MySQL database, I can get 24 req/s on Django's built-in server (with lots of other stuff running) cf 10req/s on EC2. 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: Django performance on Amazon EC2
On Tue, Jan 12, 2010 at 5:28 PM, Steve McConville < mcconville.st...@gmail.com> wrote: > > Yes, hosted in US-East-1, but I was running benchmark tests from another > EC2 > > instance in the same region, so reasonably sure it's not latency. > > I meant latencies internal to EC2; eg. what is your ping time between > the frontend and the DB box? The article I linked to reports that this > has been observed to be rising in us-east-1. Sorry if that wasn't > clear. > > My fault for not reading the linked article, sorry. Nope, not seeing bad latencies between the boxen. 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-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.
PUT with the test client
Hi,
I'm writing some tests using the Django test client for a REST API. This
API uses the PUT method and I'm running into problems with the test client,
as it appears to wish to URL encode the data into the query string.
Code is:
r = self.client.put('/json/api/endpoint', json.dumps(params),
content_type='application/json')
and the error is "ValueError: need more than 1 value to unpack" from
urlencode() in http.py
Since the data is JSON encoded it needs to go a Content-Type:
application/json in the body, without any further processing. If the put
method is replaced with the post method all works fine - the client leaves
the content alone and just puts it into the body.
The code paths in test.client.Client.put and test.client.Client.post are
different and I don't understand why - the docs (and my understanding of
HTTP) is that they should behave exactly the same in terms of entity
encoding.
Am I missing something, or is this just 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-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: PUT with the test client
On Wed, Jan 13, 2010 at 3:05 PM, Karen Tracey wrote: > On Wed, Jan 13, 2010 at 9:55 AM, Malcolm Box wrote: > >> I'm writing some tests using the Django test client for a REST API. This >> API uses the PUT method and I'm running into problems with the test client, >> as it appears to wish to URL encode the data into the query string. >> >> > Searching the tracker turns up: > > http://code.djangoproject.com/ticket/11371 > > Does that sounds like the same problem to you? If so, it has been fixed in > the 1.1.X branch and trunk. (The fix was made subsequent to the 1.1.1 > release, so it is not in 1.1.1.) > > Yes, that's exactly the problem I'm seeing, and the fix fixes it. Should have thought to search the tracker first 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.
Should Django handle uploaded files in PUT as well as POST?
Hi, I'm working on a REST-full API that allows an uploaded file to be PUT to a URL. I also need to support the X-Http-Method-Override header to turn a POST request into a PUT for clients (Flash, mobile etc) that can't do PUT. At the moment I've got the API working with POST requests, and am now moving over to PUT + implementing the override. I'm running into several places where it seems Django processes things differently if they come from a POST or a PUT. The most obvious is the HttpRequest (and derived classes) handling of _load_post_and_files(). This parses a multipart upload into a set of files in request.FILES and the rest of the POST data into request.POST, whenever request.POST is accessed. However a similar transformation isn't applied to PUT requests - so accessing request.FILES finds nothing there, and there's no equivalent request.PUT. Django-rest-interface ( http://code.google.com/p/django-rest-interface/wiki/RestifyDjango) gets round this by looking for PUT requests, then calling request._load_post_and_files() directly to populate the FILES member. This seems very brittle if anything goes near request.POST before the rest interface runs, since the request.POST access will parse the uploaded data which is then not available for reparsing - error messages such as "Cannot read more than the available bytes from the HTTP incoming data" then pop up. It seems to me that Django should process POST and PUT requests the same - i.e. the request.FILES attribute should be initialised for either if a multipart content-type is detected. Have I fundamentally misunderstood how this stuff should work? 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: OS X 10.6 Snow Leopard Setup Tutorial
On Fri, Jan 15, 2010 at 6:37 PM, Jonathan Eatherly <
jonathan.eathe...@gmail.com> wrote:
>One of these days I would like to make a DMG that sets up
> everything for the user. If anyone would be interested in a DMG single
> setup executable please let me know and maybe I will make it a weekend
> project.
>
>
I'd be eternally grateful (well, at least pretty happy) with such a DMG -
I've spent too much time fighting this particular install for my sanity.
A couple of comments from when I've done this:
- an easier way to get libjpeg is to install MacPorts (
http://www.macports.org) which gives an apt like package manager ('port')
- my incomplete notes from doing this suggest that with MySQL on the path
then easy_install MySQLdb will work. The key seems to be having my.conf on
the path
Thanks,
Malcolm
PS s/bellow/below/g in your post :)
--
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: Can't connect to MySQL server
Hi, On Thu, Jan 14, 2010 at 10:36 AM, Hans.Rauch wrote: > Hi, > > we have two separate django- and mysql-servers. Most of the time we > got no problems. From time to time we get an email with the following > error-message: OperationalError: (2003, "Can't connect to MySQL server > on '..' (4)"). If we call the submitted link, where the error occured, > we don't have any problems. > > I've also seen this, and its close cousin "Connection to MySQL server lost" when the site is under heavy (ish) load. Still not sure what's happening though, so any info you dig up would be appreciated. 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: Enter a valid value while saving fullname during registration
On Sat, Jan 16, 2010 at 7:56 PM, Praveen wrote: You seem to have forgotten to ask a question, provide an answer or start a thread of conversation. 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: Serving static files from subdomain.
On Sat, Jan 16, 2010 at 3:20 PM, nameless wrote:
> I have a site developed with django at www.example.com
>
> I want that django insert/serve static files ( images, css, js, ect )
> in/from media.example.com.
>
>
Are these files that Django is managing (e.g. via an upload), or just part
of the output HTML?
If just part of the output HTML, all you need to do is go through your
templates and change the paths in the URLs to point to
media.example.comrather than
www.example.com. For bonus points, change them to use {{ MEDIA_URL
}}/path/to/image and pass MEDIA_URL into your template functions.
> I have edited settings.py:
>
> MEDIA_ROOT = 'http://media.miosito.it'
>
> MEDIA_URL = 'http://media.miosito.it'
>
> ADMIN_MEDIA_PREFIX = 'http://media.miosito.it'
>
>
MEDIA_ROOT needs to be a directory path, not a URL - it's where Django will
store uploaded files for any ImageField members.
> And now ? What do I do ?
>
That depends :)
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: Should Django handle uploaded files in PUT as well as POST?
On Sat, Jan 16, 2010 at 4:58 AM, Russell Keith-Magee wrote: > On Sat, Jan 16, 2010 at 6:32 AM, Malcolm Box > wrote: > > > It seems to me that Django should process POST and PUT requests the same > - > > i.e. the request.FILES attribute should be initialised for either if a > > multipart content-type is detected. > > > > Have I fundamentally misunderstood how this stuff should work? > > On first inspection, I don't think you've got anything fundamentally > wrong. Support for PUT and the other 'exotic' HTTP request methods is > one area where Django support is a little bit patchy. > > Well that's good to know! > This is mostly an artefact of the vast majority of browsers providing > exactly zero support for requests other that GET and POST. As a result > Django is (by necessity) really good at handling GET and POST; PUT, > DELETE et al are all essential parts of the full HTTP spec, but > support in Django isn't quite as comprehensive. > > This is one of those areas where patches are definitely welcome. > > I'm happy to provide some patches - presumably a bug report + patch is the way to go. Which raises the question of what the correct behaviour should be, so the bug can report that it's not happening and the patch can implement. As a first pass: "On a PUT request, Django should populate request.PUT and request.FILES in the same way as for POST requests. FILES will be initialised if the content is multipart, and the PUT dictionary will have key/value pairs if the uploaded content included url-encoded form entries. If the format of the datastream is not understood, it will be left in _raw_post_data as previously, and req.FILES and req.PUT initialised to empty hashes." Does this sound reasonable as a bug/feature description? 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: Serving static files from subdomain.
On Mon, Jan 18, 2010 at 12:41 AM, nameless wrote: > Thank you for tips. > Now I want that when an user upload an image ( through forms ), then > it will be saved in media.example.com. > This is the point that I don't understand :-\ > > Does the computer running Django have access to a directory which is served by the media.example.com webserver? If it does, then just set MEDIA_ROOT to point to that directory, and any file uploaded for a FileField will be saved there. Then configure the media.example.com webserver to serve files from that directory and all will be well. You'll end up with: /a/directory/visible/to/www/and/media - contain the files (point MEDIA_ROOT here) www.example.com - Django runs here, will have URLs for any uploaded file pointing to http://media.example.com/ (from MEDIA_URL) media.example.com - Apache or whatever serving up files from the directory above. Obviously if both servers are on the same box then making a directory appear in both places is easy. If not, then you'll have to use some form of network filesystem to get the files between the boxes. 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: Should Django handle uploaded files in PUT as well as POST?
On Mon, Jan 18, 2010 at 2:04 AM, Russell Keith-Magee wrote: > On Mon, Jan 18, 2010 at 8:14 AM, Malcolm Box > wrote: > > On Sat, Jan 16, 2010 at 4:58 AM, Russell Keith-Magee> Which raises the > question of what the correct behaviour should be, so the > > bug can report that it's not happening and the patch can implement. > > > > As a first pass: > > > > "On a PUT request, Django should populate request.PUT and request.FILES > in > > the same way as for POST requests. FILES will be initialised if the > content > > is multipart, and the PUT dictionary will have key/value pairs if the > > uploaded content included url-encoded form entries. > > > > If the format of the datastream is not understood, it will be left in > > _raw_post_data as previously, and req.FILES and req.PUT initialised to > empty > > hashes." > > > > Does this sound reasonable as a bug/feature description? > > Sounds reasonable to me. I can't think of any obvious reason that the > handling for PUT should differ from POST. > > Ticket http://code.djangoproject.com/ticket/12635 raised. Patches to follow. 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: Should Django handle uploaded files in PUT as well as POST?
On Mon, Jan 18, 2010 at 9:23 AM, Masklinn wrote: > On 18 Jan 2010, at 03:04 , Russell Keith-Magee wrote: > > > > On Mon, Jan 18, 2010 at 8:14 AM, Malcolm Box > wrote: > >> On Sat, Jan 16, 2010 at 4:58 AM, Russell Keith-Magee > >> Which raises the question of what the correct behaviour should be, so > the > >> bug can report that it's not happening and the patch can implement. > >> > >> As a first pass: > >> > >> "On a PUT request, Django should populate request.PUT and request.FILES > in > >> the same way as for POST requests. FILES will be initialised if the > content > >> is multipart, and the PUT dictionary will have key/value pairs if the > >> uploaded content included url-encoded form entries. > >> > >> If the format of the datastream is not understood, it will be left in > >> _raw_post_data as previously, and req.FILES and req.PUT initialised to > empty > >> hashes." > >> > >> Does this sound reasonable as a bug/feature description? > > > > Sounds reasonable to me. I can't think of any obvious reason that the > > handling for PUT should differ from POST. > > Does that mean the request object could have arbitrary HTTP_METHOD > attributes when it can parse the content as keys:values? At least if the > MIME of the request is `application/x-www-form-urlencoded`? > > I mean as far as I know nothing forbids creating custom HTTP methods > (indeed, that's what e.g. WEBDAV does) and some of these custom methods > could very well have the same properties as POST. > I don't see why not, although that's not what I'm planning to submit patches for - I'm just aiming to cover PUT ie to complete the support for the core HTTP methods that are allowed entity bodies. So the HttpRequest object will grow a new PUT attribute, but nothing else. 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.
Django and caching when data is updated
Hi, On the quest for performance I'm now having a look at Django's caching framework. I've got a simple question that I can't find the answer to: if the data that a view depends on changes, does Django do anything smart to invalidate the cache for that view, or is it left to the programmer? If the later (which is what I suspect), then is there an easy way to find out what the tag under which the view result has been cached by the middleware is? I'm imagining a scenario where I have a view that handles a POST and GET of some model(s). Whenever there's a POST the data can be assumed to have changed, so the cache should be flushed. 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: Django and caching when data is updated
Hi, On Thu, Jan 21, 2010 at 7:35 AM, Russell Keith-Magee wrote: > On Thu, Jan 21, 2010 at 7:47 AM, Malcolm Box > wrote: > > > > I've got a simple question that I can't find the answer to: if the data > > that a view depends on changes, does Django do anything smart to > invalidate > > the cache for that view, or is it left to the programmer? > > >Your suspicions are correct - there is no systematic cache > invalidation tied to Django's models. > > Thanks for the confirmation! > If you want to invalidate a specific view, you will need to use the > cache key tools to django.utils.cache to reconstruct the key for the > view that needs to be invalidated. See the cache middleware for > examples of usage. > So a higher-level question - is this the prefered design approach - have the views that alter data explicitly invalidate the views in the cache for the ones who's data has been changed? It feels a bit too tightly coupled to me - and fragile if new views are added. What's the recommended approach, or what have others done that's worked? A few more details on my app if that helps: it's a voting app, so some data (e.g. the polls, questions etc) change infrequently, whereas the number of votes and current result change frequently. I'm aiming to scale to handle tens of thousands of votes per second. 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: Templating problem: equal symbol "=" escaped to "=3D"
Are you sure it's django templates that are doing the escaping? =3D is the mime escaping for = - could it be something else in your email processing chain that's escaping the sign? Malcolm On 1/21/10, Enrico Sartorello wrote: > Hi, > i'm using Django template system to render some text files (not HTML pages) > that I use to send emails. > > I have a problem: in a template file, any occurence of the "=" symbol is > escaped to "=3D" no matter what is placed before or after it. > '=' is strangely escaped to '=3D' even if autoescape is off or the > containing string is marked with 'safe' filter. > > What's wrong with that? > > Please help me because I've lost a lot of time trying to solve this issue! > > Thanks in advance :-) > > -- > Enrico Sartorello > -- Sent from my mobile device -- 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: Need your expertise
On Fri, Jan 22, 2010 at 9:03 AM, Jigs wrote: > We are currently deciding if Django Framework will suit our needs. > > Templates and Python is a must requirement for the project. Reporting > and Monitoring modules will be created in the future. Please advise if > we are going in the right direction if ever we are using Django. > > Django does all those things. It's not really possible to tell you whether Django is suitable for your app - only you know all the requirements and what you want to do. Django can probably be used to create any sort of web application - what changes is how easy it is, and how much you have to do versus getting off-the-shelf. Your best bet is to read the Django docs to get a feel for what it does, and then evaluate yourself. 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: Should a decorator be used here or should I do something else.
If it's different instances of the model that should have age-restrictions applied then I would be tempted to push this down to the model layer by creating a new Manager called e.g. age_filtered and then use that in view: q = Data.age_filtered(age).filter(id=23) You could even make the default manager the age filter so that if a view forgets to use the age_filtered() manager then they only get "safe" all ages content (assuming such a thing exists). Malcolm On Thu, Jan 21, 2010 at 5:13 PM, Bill Freeman wrote: > A decorator is certainly a clean way to apply consistent checking to a > bunch of > views. But it is primarily useful if the selection of the view > function by the urlconf > gives you all you need to know about for what age groups the *CONTENT* is > appropriate. > > If, on the other hand, different rows in the same table (different > instances of the > same model) are appropriate for different age groups, then you're stuck > with > either doing your object query in the decorator and passing it to the > view, which > might be too magic. (Maybe pass a base queryset to the view for > further filtering, > but still pretty magic.) > > A shared function that you call from the view to filter a queryset based on > age > criteria might feel more explicit. > > Bill > > On Wed, Jan 20, 2010 at 5:15 PM, Jeffrey Taggarty > wrote: > > Hi Guys, I have a bit of a dilemma in terms of design of a small web > > application... > > > > I have this requirement where content is being served by age group. On > > first load the user selects their age group and I store that in the > > cookie. I read that cookie and query content for the pages based on > > that agegroup cookie. My question is should I use a decorator to check > > the cookie on every new page requested to make sure they're getting > > the proper content served based on that agegroup in the cookie? I have > > about 6 functions in total in my views. I was thinking just writing a > > decorator to handle that but I am not sure that's the best way to go > > about this. > > > > Thanks > > > > > > Jeff > > > > -- > > 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. > > > > -- 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: Templating problem: equal symbol "=" escaped to "=3D"
Try it and see! Malcolm On Thu, Jan 21, 2010 at 4:05 PM, Enrico Sartorello < enrico.sartore...@gmail.com> wrote: > Ok maybe I got it. > > I found those "=3D" symbols just looking at the output of the Python SMTP > server that simulates the email process. > > I think that those mime escaped characters will be correctly converted back > to "=" symbols when processed by a mail client. > > Am I correct? > > > > On Thu, Jan 21, 2010 at 4:49 PM, Enrico Sartorello < > enrico.sartore...@gmail.com> wrote: > >> You're right, it's the mime escaping! >> >> In order to send emails I simply use: >> >> render_to_string(file) >> send_mail() >> >> How can I send plain text messages with '=' symbols without getting it >> escaped? >> >> >> >> On Thu, Jan 21, 2010 at 4:20 PM, Malcolm Box wrote: >> >>> Are you sure it's django templates that are doing the escaping? =3D is >>> the mime escaping for = - could it be something else in your email >>> processing chain that's escaping the sign? >>> Malcolm >>> >>> On 1/21/10, Enrico Sartorello wrote: >>> > Hi, >>> > i'm using Django template system to render some text files (not HTML >>> pages) >>> > that I use to send emails. >>> > >>> > I have a problem: in a template file, any occurence of the "=" symbol >>> is >>> > escaped to "=3D" no matter what is placed before or after it. >>> > '=' is strangely escaped to '=3D' even if autoescape is off or the >>> > containing string is marked with 'safe' filter. >>> > >>> > What's wrong with that? >>> > >>> > Please help me because I've lost a lot of time trying to solve this >>> issue! >>> > >>> > Thanks in advance :-) >>> > >>> > -- >>> > Enrico Sartorello >>> > >>> >>> -- >>> Sent from my mobile device >>> >>> -- >>> 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. >>> >>> >>> >>> >> >> >> -- >> Enrico Sartorello >> > > > > -- > Enrico Sartorello > > -- > 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: get all foreign keys that point to
The list of all drivers in a team is (assuming self is a team instance) drivers = self.driver_set().all() Hope that helps. Malcolm On Thu, Jan 21, 2010 at 2:49 AM, Ether Joe wrote: > Hello there, quick (hopefully) question for you - how do I get a list > of records in a foreign table that point back to the object making the > query? > > For example - a Formula One racing team, where each Team has 0 or more > Drivers, and each Driver can be a member of only one Team. How do I > get a list of all Drivers that point to a specific Team, and then > display them on the Team page? Perhaps using a TeamAdmin or > TeamManager class? > > class Team(models.Model): >... > class Driver(models.Model): >... >team = models.ForeignKey(Team) > > I looked at using a TeamAdmin with an InlineModelAdmin pointing to > Driver. This gets me the Drivers on the Team page. But I don't want to > edit the Drivers - just display. Also, I want to do things with the > queryset (eg., count them). > > 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.
Converting Django testclient code to run as black-box tests
Hi, I've got an existing unit test suite using the django.test.TestCase class that exercises the HTTP interface of the site, but running under Django's test harness. I'd like to turn this into a black-box test suite, using real HTTP to talk to the server remotely. Obviously some tests e.g. the assertTemplateUsed test would be impossible, but most of my tests are of the form client.put/client.get then assertContains/assertEquals. These should be easy to transfer to an integration-level test suite. Has anyone tried doing something like this or know of existing code that can do 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.
Re: Converting Django testclient code to run as black-box tests
Hi,
On Sat, Jan 23, 2010 at 11:55 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:
> On Sat, Jan 23, 2010 at 6:40 PM, Malcolm Box
> wrote:
> > Hi,
> >
> > I've got an existing unit test suite using the django.test.TestCase class
> > that exercises the HTTP interface of the site, but running under Django's
> > test harness.
> >
> > I'd like to turn this into a black-box test suite, using real HTTP to
> talk
> > to the server remotely. Obviously some tests e.g. the assertTemplateUsed
> > test would be impossible, but most of my tests are of the form
> > client.put/client.get then assertContains/assertEquals. These should be
> > easy to transfer to an integration-level test suite.
> >
> > Has anyone tried doing something like this or know of existing code that
> can
> > do it?
>
> It sounds like you've got a case of using the wrong shovel to nail in
> a screw. As the testing docs indicate, if you want to do live browser
> testing, you should use a live browser test tool like twill, Selenium
> or Windmill. Django's test client is a way to functionally invoke (and
> test) views as seen by Django. If you want a full integration level
> test suite, you should be looking at other tools.
>
>
That's a lovely metaphor, however I'm not sure I'm hammering a screw. The
test cases in question are not for a browser-consumed pages, but for a REST
API. For webpages I would indeed use Selenium or somesuch, but that's not
the case.
I have a big bunch of testcases of the form:
r = self.client.get('/api/function1/')
self.assertContains(r, 'blah')
data = json.loads(r.content)
# do more stuff to verify the JSON
There's nothing browser-ish here - it's all API level testing.
Re-writing these in another framework so I can test the same API when it's
on a server rather than just running under a local test harness seems wrong,
not least in terms of DRY. But without it, I have a test gap if something
works under Django's server but not in deployed mod_python/mod_wsgi. Can
you tell I've just been bitten by this problem?
What I'm thinking of is replacing the Django TestCase object with a new one
that implements get() and post() via urllib, and fakes up enough of the
HttpResponse object to make the tests work.
I thought this might be generally useful enough that someone might have
already done it, hence the posting.
There is a long standing ticket (#2879) that proposes to improve the
> integration of these tools with Django. This ticket wasn't quite trunk
> ready last time I looked at it, but I'm still in favor of the general
> idea it is advocating. However, but even without fixing that ticket,
> it is possible to use them - it's just not as clean as it could be.
>
>
And lo, it is the case! Thanks for the pointer to this stuff - links from
it appear to do almost exactly what I want to be able to do, at least in
terms of talking to a separate server.
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: extend queryset field lookups for time
On Tue, Jan 26, 2010 at 9:14 AM, Henrik Genssen wrote:
> how would I extend the field lookup to get somethnng like this:
>
> SELECT ... WHERE EXTRACT('hour' FROM pub_date) > 20
> what is for MYSQL:
> SELECT ... WHERE HOUR(pub_date) > 20
> to get all entries where the timepart of pub_date is grater then 8pm
>
>
Have a look at the extra() method on the queryset -
http://docs.djangoproject.com/en/1.1/ref/models/querysets/#queryset-api
With that you can inject the relevant SQL to extract a part of a datetime
field and filter by < > = etc.
Alternatively, store your table with the datetime split into year, month,
day, hour, minute etc fields. You could add processing to the model's
save() function to do this transparently.
As far as I know there's no built-in way to do what you want.
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 RSS, maybe error in programming.
On Mon, Jan 25, 2010 at 11:18 PM, Felipe Catojo wrote: > Hello Guys, > > I have tried to configure RSS in my blog application and when I try to > access the objects (blog entries) that would be returned by the RSS > app, the RSS app return a strange message that I don't understand: > > http://www.catojo.com.br/feeds/latest/ > > What's the error message you see? That link returns what looks like valid RSS 2.0 to me, and Google Reader handles it with no 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-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: Cookie Tip
Hi, On Mon, Jan 25, 2010 at 8:00 PM, cootetom wrote: > The tip here is to add the following to your settings.py file > > SESSION_COOKIE_PATH = '/;HttpOnly' > > Useful information - however be warned this isn't a panacea. See http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly for which browsers and which attacks this prevents. Even so, it adds another layer of security and that's a good thing. 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: login failure
On Mon, Jan 25, 2010 at 6:16 AM, harryos wrote:
> On Jan 24, 10:45 pm, Daniel Roseman wrote:
> > You put them in your project's settings.py (which, through some magic,
> > is imported via django.conf). You should not be editing any of the
> > code inside Django itself, unless you know what you're doing.
>
>
> Thanks for the reply..I added the login data to my project settings
> and tried to post a link to delicious site using my yahoo id as
> below.I can manually login at yahoo page using the same login
> data .But when I try to do the following I get an
> raise PyDeliciousUnauthorized, "Check credentials." error
>
> >>> from pydelicious import DeliciousAPI; from getpass import getpass
> >>> pwd = getpass('Pwd:')
> Pwd:#i entered my password here
> >>> a = DeliciousAPI('myusername', pwd)
> >>> a.posts_add("http://my.com/";, "title", tags="my tags")
>
> can anyone help me find out why this is happening?
>
>
A guess - whatever format getpass() is returning isn't the format/encoding
that the DeliciousAPI call is needing. Commonly that's because one is
dealing with the password in plaintext, and the other in some hashed format.
As I say - a guess. I've never looked at either, but that's where I'd
start. Oh and step into the DeliciousAPI code to see what's happening/where
the error is occurring.
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: View doesn't return HttpResponse object
That code looks fine to me. I'd suggest sticking an "import
pdb;pdb.set_trace()" as the first line of the view, then stepping through
the code (run the server with manage.py runserver). That should quickly
highlight any areas where the code flow isn't as you expect.
Cheers,
Malcolm
On Wed, Jan 27, 2010 at 10:38 AM, Ashok Prabhu wrote:
> Hi,
>
> I have the following view which throws the error "The view
> TCDB.viewdb.views.dbout didn't return an HttpResponse object." I have
> tried various indentation for the return statement. But it doesn't
> seem to help. Can somebody help?
>
> def dbout(request):
> try:
> filter_string= request.GET.get('filter_string', '')
> table_name=request.GET.get('table_name','')
> field_name=request.GET.get('field_name','')
> if field_name=='hostid':
> results=eval(table_name).objects.filter(hostid__icontains=str
> (filter_string)).values()
> elif field_name=='hostname':
> results=eval(table_name).objects.filter(hostname__icontains=str
> (filter_string)).values()
> elif field_name=='plat_manu_name':
> results=eval(table_name).objects.filter
> (plat_manu_name__icontains=str(filter_string)).values()
> elif field_name=='mac':
> results=eval(table_name).objects.filter(mac__icontains=str
> (filter_string)).values()
> return HttpResponse('No Exception')
> except:
> return HttpResponse('Exception Reached')
>
>
> Thanks,
> ~Ashok.
>
> --
> 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: View doesn't return HttpResponse object
On Wed, Jan 27, 2010 at 2:54 PM, Karen Tracey wrote: > On Wed, Jan 27, 2010 at 9:45 AM, Malcolm Box wrote: > >> That code looks fine to me. I'd suggest sticking an "import >> pdb;pdb.set_trace()" as the first line of the view, then stepping through >> the code (run the server with manage.py runserver). That should quickly >> highlight any areas where the code flow isn't as you expect. >> >> > Single stepping through in the debugger is a good suggestion. However, the > code as posted is not fine, since the blocks under try and except are not > indented any further than the try/except statements, and they need to be. > What was posted can't possibly be what is actually running since the posted > code will generate an IndentationError on an attempt to import it. > > It was indented if you looked in the original message text - I suspect your (and my) default email program is stripping leading spaces. 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: Number of total items in the database
On Wed, Jan 27, 2010 at 6:10 PM, Zeynel wrote: > Hello, > > How do I query the the total number of items in the database to put in > a template? > > I want to add to this page http://swimswith.com/search/ that "There > are currently [X] lawyers in the database." > > Have a look at the count() method on Querysets. So something like: Lawyers.objects.count() will be the answer. 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: Reasons why syncdb ignores an application?
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.
Making a model field have a default value
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: REST & Django
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.
Problem with Last-modified header and Apache/mod_python
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.
Speeding the code-test-debug cycle
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.
Re: Speeding the code-test-debug cycle
Hi, Thanks for the suggestions. 2010/2/2 Phlip > 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.
Re: Problem with Last-modified header and Apache/mod_python
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
> 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: update with where clause constraints?
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: simple, input from user and database earch result
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: Django with Jquery
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: How can I apply ordering through a M2M join model?
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: ImageField admin preview not working
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: fixtures getting created with terminal message prefixed
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: Django REST and FILEFIELD field
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: Forcing HTTPS in admin
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: Specific models without a database table
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: how to invalidate per-view cache?
On 19 August 2011 23:32, galgal 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: Django Test Corrupted Test Data
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 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 > > > > Sender: django-users@googlegroups.com > > Date: Fri, 19 Aug 2011 12:13:24 > > To: Django users > > 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: Best approach to handling different types of Users
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: Help installing django-sentry
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: Problem updating data
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 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: Pagination of more than one field
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: django and thrift
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
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: In unitTest, GET Formset returns 302 instead of 200
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: django and thrift
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: Is it possible to run from Django script?
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: CAS and Django cache
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: Django tutorial hasn't received an update for 1.3
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 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: Login problems under heavy load
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: Caching at model class level
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: memcached - Errors and Solution - please provide comments!
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.
ANN: Two-level caching for Django
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: Problem in Configuring the database
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.
Re: UTF-8 and files automatically created
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: Memcached backend - caching data with infinite timeout
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: Memcached backend - caching data with infinite timeout
On 17 May 2011 11:15, Tom Evans wrote: > On Tue, May 17, 2011 at 11:03 AM, Malcolm Box > 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: How do you organize your deployment enviroment
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: Userprofile, signal and admin inline edit.
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: Admin broken with large data table
On Mar 29, 4:31 pm, Malcolm Box wrote: > On Mar 29, 2:48 pm, Jacob Kaplan-Moss wrote: > > > On Tue, Mar 29, 2011 at 5:56 AM, Malcolm Box 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: Caught RuntimeError while rendering: invalid label:
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: caching ajax json (post)
On 27 May 2011 08:12, Олег Корсак 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: primary key auto increment with PostgreSQL and non Django standard column name
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 because you are subscribed to the Google Groups
"Djan
Re: choice_set.all()
On 29 May 2011 06:20, bahare hoseini 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: signals pre_save vs model's save()
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: How to create user on mobile app for Django site?
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: Disable debug logging for django.db.backends?
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: Odp: Re: signals pre_save vs model's save()
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 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: repr(request.session)
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: Users not logging out
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: django transactions.
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: Re: Odp: Re: signals pre_save vs model's save()
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: 2 projects based on the same codebase
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: django transactions.
On 8 June 2011 11:07, Marc Aymerich wrote: > On Tue, Jun 7, 2011 at 11:53 PM, Malcolm Box > wrote: > > n 7 June 2011 15:16, Marc Aymerich 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: Updating static files: Still in browser cache
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: Updating static files: Still in browser cache
Sent from my iPhone, please excuse any typos On 9 Jun 2011, at 14:21, DrBloodmoney wrote: > On Thu, Jun 9, 2011 at 9:16 AM, Malcolm Box wrote: >> 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. > > 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: Boolean field, unexpected behavior
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: Authentication in API (REST)
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: Authentication in API (REST)
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: Updating static files: Still in browser cache
On 10 June 2011 14:54, Thomas Guettler wrote: > On 09.06.2011 19:18, Malcolm Box wrote: > > On 9 Jun 2011, at 14:21, DrBloodmoney wrote: > > > >> On Thu, Jun 9, 2011 at 9:16 AM, Malcolm Box > wrote: > >>> On 9 June 2011 08:09, Thomas Guettler 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)
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: Why does OpenLayers not load in django with this template ?
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: Strange value_from_object() return value (2L returned instead of unicode string)
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: Strange value_from_object() return value (2L returned instead of unicode string)
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: csrf protection and testing with tsung
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: csrf protection and testing with tsung
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: Possible interest in a webcast/presentation about Django site with 40mil+ rows of data??
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&A 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.
