Re: Django 1.6.0 over python 3: mysql?

2012-12-06 Thread Ian Clelland
On Fri, Nov 23, 2012 at 6:02 AM, ajendrex <hurbi...@gmail.com> wrote:

> Hello,
>
> I'm new to django and I'm going directly to use it over python 3 (I have
> been using python 3 for mor than one year). However, the MySQLdb library
> doesn't support python 3 yet. Is there a way of connecting django to mysql
> over python3? If not, any plan to get it in the near future?
>
>
I'm sorry I didn't see this when you asked (two weeks ago now).

I wholeheartedly support your move to PostgreSQL, but if anyone else on the
list is stuck in the same situation, about a year ago I adapted the Django
MySQL backend to use PyMySQL[1], which is a pure python interface to MySQL,
is essentially a drop-in replacement for MySQLdb, and *is* Python
3-compatible.

You can just easy_install (or pip install) django-mysql-pymysql, and use
'mysql_pymysql' as your database backend, and you should be set.

If it breaks, feel free to submit improvements at
https://github.com/clelland/django-mysql-pymysql :)

Alternately, you could wait a bit; Andy Dustman mentioned on his blog a
couple of months ago that a soon-upcoming version of MySQLdb could be
released with Python 3 support [2]

[1] https://github.com/petehunt/PyMySQL

[2] http://mysql-python.blogspot.ca/2012/09/a-brief-history-of-mysqldb.html

-- 
Regards,
Ian Clelland
<clell...@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: Disabling CSRF is not working.

2012-10-05 Thread Ian Clelland
On Friday, October 5, 2012, Bill Freeman wrote:

> I believe that I read somewhere that newer Djangos force the CSRF
> middleware even if it's not listed in MIDDLEWARE_CLASSES.


You might be thinking of the CSRF context processor, which is always
enabled, no matter what is in settings. Even the most recent docs don't say
anything about forcing the middleware.

>
> You could dive into the middleware code to see how this happens, and
> come up with a stable strategy to circumvent it.  Or you could just
> fix the necessary views and templates.  There is, after all, a chance
> that you will want to be able to upgrade this site without jumping
> through hoops.
>
> On Thu, Oct 4, 2012 at 4:56 AM, Laxmikant Gurnalkar
> <laxmikant.gurnal...@gmail.com <javascript:;>> wrote:
> > Hi, Guys
> >
> > Disabling CSRF is not working.
> > These are my midlewares., Removed {% csrf_token %} all templates.
> >
> > MIDDLEWARE_CLASSES = (
> > 'django.middleware.common.CommonMiddleware',
> > 'django.contrib.sessions.middleware.SessionMiddleware',
> ># 'django.middleware.csrf.CsrfViewMiddleware',
> > 'django.contrib.auth.middleware.AuthenticationMiddleware',
> > #'django.contrib.messages.middleware.MessageMiddleware',
> > #'django.middleware.csrf.CsrfResponseMiddleware',
> > # 'igp_acfs.acfs.disablecsrf.DisableCSRF',
> > )
> >
> >
> > Also tried by writing disablecsrf.py like this :
> >
> > class DisableCSRF(object):
> > def process_request(self, request):
> > """
> > """
> > setattr(request, '_dont_enforce_csrf_checks', True)
> >
> >
> > Thanks in Advance!!!
> >
> > Laxmikant
> >
> > --
> > 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<javascript:;>
> .
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com <javascript:;>.
> > 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<javascript:;>
> .
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com <javascript:;>.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
Regards,
Ian Clelland
<clell...@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 on legacy Postgres database with encoding WIN1252

2012-10-04 Thread Ian Clelland
What is that character supposed to be?

According to the Wikipedia page on CP1252, 0x81 is an unused character
position. There is a mention that it might map to some ISO-2022 control
code with no unicode equivalent.

I'm not sure where the error message is coming from, though -- if it was in
the python layer, you would see something like:

UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position
0: character maps to 

Possibly the postgresql interface is trying to convert it to UTF8 for
transfer, and failing, or maybe the psycopg2 layer can't decode it. Is
there any other info you can provide about the error message?

It may end up that you just have to clean the data in the database to be
able to use it.

Ian

On Thu, Oct 4, 2012 at 9:57 AM, Janeskil1525 <janeskil1...@gmail.com> wrote:

> Hi all
>
> I'm new Django user. I have a legacy system based on a Postgres 9.1
> database that is using encoding WIN1252. When i try to retrie data from one
> table I get the following error
>
> >>character 0x81 of encoding "WIN1252" has no equivalent in "UTF8"<< ,
> does that mean i cant use Django together with this database or is there
> some setting i need to change ?
>
> All help appreciated
>
> Thank you in advance!
>
>
> Jan Eskilsson
>
> --
> 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/-/EXpvuuttJ64J.
> 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.
>



-- 
Regards,
Ian Clelland
<clell...@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.



Catch or raise exception designissue

2012-07-31 Thread Ian Clelland
[sorry for the late response; this got lost in drafts, but it's enough of a
sore point for me to want to post it]

On Sun, Jul 15, 2012 at 12:30 PM, Jani Tiainen
<rede...@gmail.com<javascript:_e({}, 'cvml', 'rede...@gmail.com');>
> wrote:

> I think "letting to explode" is all about coloring the bike shed. It all
> depends on a API contract - if parameter is required (thus meaning missing
> it is a critical error) it should explode.
>
> In case of incorrect request I prefer to raise 400 (Bad Request) with some
> explanation what went wrong. Since 500 is usually meant for "catch all"
> unexpected errors that happened in web server and server can't be more
> precise what happened. I've done that according to RFC 2616 (HTTP 1.1
> Specification) where is said that 4xx codes are meant for "client side
> error" (Section 10.4), and 5xx which means "server error" (Section 10.5)
>
> But I think all of that is matter of taste...
>
>
I wouldn't call it a matter of taste; this is the spec for communicating
over HTTP.

Certainly, if you have full and complete control over the server, and over
every client, then by all means use 500 errors to mean whatever you want.
You could also signal an error with a 200 OK message, or just make up your
own status codes.

Status codes have meaning though, which is important as soon as you want to
open up your interface to any other clients. A 400-series code means that
the client request had a problem, and the specific code tells the client
whether there is anything that can be done about it.

A 500 error, on the other hand, means that there is an error (read: bug) in
the web server code. Something happened (almost certainly in response to a
client request) that the server was not properly coded to handle, and the
result was an unexpected exception.

The distinction is important: it communicates who has the responsibility
(or at least the capability) to fix the error.

As developers, we should be reporting 400-series errors every time we can
detect an issue with a request, as a courtesy to clients. We should never
deliberately be creating 500 errors. The only responsible thing to do when
a 500 is seen in the logs is to track down the source of it and fix the bug.

-- 
Regards,
Ian Clelland
<clell...@gmail.com <javascript:_e({}, 'cvml', 'clell...@gmail.com');>>


-- 
Regards,
Ian Clelland
<clell...@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: Ignore apostrophes using django-postgresql

2012-07-20 Thread Ian Clelland
The queryset's extra() method can help you with that:

MyModel.objects.extra(where=["replace(db_column_name, , '') = %s"],
params=["rockn burger"])

(Be careful if you're typing that in manually -- there are lots of
single-quotes in it)

Ian

On Fri, Jul 20, 2012 at 4:02 PM, Ada Pineda <elizethpin...@gmail.com> wrote:

> Hello
>
> I'm asking for your help because I need to do a query on a table that has
> a field that contains apostrophes, but I need to ignore them (apostrophes)
> when I'm doing the query. I have to save the data as it is, so I can't just
> take away those apostrophes before saving to the database. I mean, if the
> database has "rock'n burger" and a user types "rockn burger", I need to get
> the value with apostrophe from the database.
>
> Can anyone help me?
>
> Thanks a lot!
>
> --
> 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/-/lxGzVjrwQgMJ.
> 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.
>



-- 
Regards,
Ian Clelland
<clell...@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: model translationissue

2012-07-12 Thread Ian Clelland
On Thursday, July 12, 2012, Phil wrote:

> Hi,
>
> I'm trying to translate form names from a model. I have a working contact
> form for example and have the following code
>
> 
>
> from django import forms
> from django.core.mail import mail_managers
> from django.utils.translation import ugettext_lazy as _
>
> class ContactForm(forms.Form):
> name = forms.CharField(_('name'), max_length=100)
>
>
> ==
>
> It adds it to my .po file ok, but when I run it in the browser I get the
> following error...
>


> Exception Type: TypeError at /contact/
> Exception Value: __init__() got multiple values for keyword argument
> 'max_length'
>
>
>
max_length is the first argument to the CharField constructor. You provided
it twice (accidentally, I'm sure): once as the first argument, and again as
a named parameter.

If the argument "_('name')" is supposed to be the field label, then you
should pass it explicitly as that keyword art, like this:

name = forms.CharField(label=_('name'), max_length=100)

Ian


-- 
Regards,
Ian Clelland
<clell...@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: 'CSRF verification failed." from django.contrib.comments. can you help solve it? django 1.3

2012-06-28 Thread Ian Clelland
On Thu, Jun 28, 2012 at 9:14 AM, brycenesbitt <digitalbitstr...@gmail.com>
 wrote:

> I'm using django.contrib.comments and get 'CSRF token missing or
> incorrect.' when previewing or submitting a comment.  I have:

...



The HTML looks like it has the csrf security_hash in the proper place:
> 
>  />
> 
> 
> ...



The "security_hash" field that you see is part of the comments app, and is
not the CSRF token. That needs to be output by a {% csrf_token %} tag (or
its equivalent). If it's working, you should see another hidden input
field, which looks like this:





The comments app normally does that automatically -- it's part of
django/contrib/comments/templates/form.html -- Are you overriding the
comment form in your own app? If so, you need to include the call to {%
csrf_token %} yourself.

@csrf_protect  #does not matter if this is here or not
>

No, if you have the CSRFViewMiddleware installed, then you don't need this
line at all.

-- 
Regards,
Ian Clelland
<clell...@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: What is Django's behavior when a request is interrupted?

2012-05-29 Thread Ian Clelland
On Tuesday, May 29, 2012, John Boxall wrote:

> Consider the following code:
>
> def view(request):
>> import pdb;pdb.set_trace()
>> # Make a bunch of databases updates
>> return HttpResponse('OKAY')
>
>
> I boot up the Django devserver and make a request from my browser. It is
> routed by Django to `view`. When the debugger launches, I cancel the
> request in my browser.
>
> It seems as though Django continues executing the code in the request
> path. Is this the expected behavior?
>

As a WSGI application, Django should have no
idea that the connection has been closed. The connection to the client is
just another resource, like a database connection or a memcache server.
Nothing will happen asynchronously to raise an exception; you'll only see
an exception at the point where you try to use the resource.


> If the connection has 'gone away' are there any circumstances where Django
> will raise an exception in the regular request path?
>

You're only going to see an exception at the point where you try to write
out to the http response object, and your wsgi server fails because the
other end of the connection is closed.

In django 1.4, http response is lazy, as well, so even writing directly to
it will probably not raise an exception until the view has returned, anyway.

Ian


> Cheers,
>
> John
>
> --
> 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/-/M-mNNXY3vbQJ.
> To post to this group, send email to 
> django-users@googlegroups.com<javascript:_e({}, 'cvml', 
> 'django-users@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com <javascript:_e({}, 'cvml',
> 'django-users%2bunsubscr...@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>


-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: HELP with unicode!!!!!

2012-05-01 Thread Ian Clelland
On Tuesday, May 1, 2012, dizzydoc wrote:

> Hi ,
>
> i have lost a lot of time looking for a solution.
>
> My problem is, while i a reading csv in python using
>
> csv_file  = open(path_file, "rb")
> reader = csv.reader(csv_file)
>
> whenever i perform any operation on the string returned in each cell i
> get this error
>
> *** UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0'
> in position 34: ordinal not in range(128)


It's a long-standing limitation with the python csv module that it does not
handle Unicode well. In fact, it's one of the first things mentioned in the
docs:

 http://docs.python.org/library/csv.html

Further down that page, though, is a snippet of code that you should be
able to use (search the page for "unicode_csv_reader")

If that doesn't work, come back here with some code that you've tried and
hopefully we can find a solution

Ian


> i tried decoding the value as
>
> val.decode('utf-8')
>
> ...this helped to reduce a few encodings but gets stuck for
> the encoding "\xa0"
> Please HELP!
>
>
>
>

-- 
Regards,
Ian Clelland
<clell...@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: HttpResponse_is_string is removed Django 1.4

2012-04-06 Thread Ian Clelland
On Thu, Apr 5, 2012 at 6:07 PM, Rajat Jain <rajat...@gmail.com> wrote:

> Hi,
>
> I have noticed that the class variable HttpReponse._is_string (in
> django/http/__init__.py) is removed in Django 1.4. I was setting this
> variable in a couple of places in my code, so that piece of code is
> breaking in Django 1.4. Do you know if this field is required at all? If
> not, is it just safe to remove this field altogether from my code?
>

Were you setting it to True or False?

If your code sets it to True, then this should be safe to remove -- in
Django 1.4, HttpResponse always renders its output as a string, converts
its contents to a string, regardless of what type of data it has been given.

If you were setting it to False, for some reason, then you'll have to come
up with a different way of accomplish whatever you're trying to do.

(The original ticket was https://code.djangoproject.com/ticket/16494, and
you can see the changes that were made for 1.4 here:
https://code.djangoproject.com/changeset/16829)




-- 
Regards,
Ian Clelland
<clell...@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: Questions about UnicodeDecodeError

2012-04-04 Thread Ian Clelland
On Monday, April 2, 2012, Ali Mesdaq wrote:

> I did have UTF-8 in the db before but then when I was inserting(done by a
> script) values in I would get errors. I really want to avoid doing
> conversions before I insert the data so I can maintain the data in the
> exact format as it was seen in.


This, in general, isn't going to be possible. Even if you get it to the
point where it looks like its working, you may still end up with silent
data corruption, and not be able to retrieve your data when you need it.

If your database column only supports ASCII, and you cant change the
database, then your best option is probably going to be to use a strict
ASCII encoding, like base64 or base85. If you are pretty sure that the data
is *mostly* ASCII, then you could go with something like quoted-printable.
The point, though, is that you need to do *something* to your data to
coerce it into the ASCII range before you put it in the database.

As long as you remember to encode the data on save, and decode it (once!)
before displaying it, you should be able to get it to work.

Ian


>  I may be forced into doing that it seems
> to make django even work. I tried to get my app to work by creating the
> __unicode__ method return a string of "blah" and it still dies on me.
>
> Thanks,
> Ali Mesdaq
> Security Researcher
> Cell:  +1 (619) 952-8488  |  Fax:  +1 (408) 321-9818
> Email:  ali.mes...@fireeye.com
>
>
> Next Generation Threat Protection
> http://www.FireEye.com 
>
>
>
>
>
>
>
> On 4/1/12 3:04 PM, "Bill Freeman"  wrote:
>
> >If you can, switch to UTF-8 in the db.  Web traffic can arrive in a
> >variety of
> >encodings, and while the headers tell the server how to make unicode out
> >of it, but by having the db set for ASCII, you limit what you can store
> >(since
> >not all unicode characters can be converted to ASCII.
> >
> >On Fri, Mar 30, 2012 at 7:45 PM, Ali Mesdaq 
> >wrote:
> >> I have a situation where I am reading data that I have no control over
> >>and
> >> inserting it into a db. The data is http headers. I am storing them in
> >> postgres db in a text field and the db encoding is SQL_ASCII. Since the
> >> data can be anything even non compliant http headers with anything for
> >>its
> >> values I don't want to modify the data before I store it in the db.
> >> However this is causing issues with certain values causing the
> >> UnicodeDecodeError. For example I have a specific case where the user
> >> agent is set to 'KC\xd4\xda\xcf\xdf\xc9\xfd\xbc\xb6'. I have been trying
> >> to look for a way to deal with these cases gracefully in the models
> >> __unicode__ method but nothing I have tried has worked.
> >>
> >> Thanks,
> >> Ali Mesdaq
> >> Security Researcher
> >> Cell:  +1 (619) 952-8488  |  Fax:  +1 (408) 321-9818
> >> Email:  ali.mes...@fireeye.com
> >>
> >>
> >> Next Generation Threat Protection
> >> http://www.FireEye.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.
> >>
> >
> >--
> >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: internationalization makemessage don't work

2012-02-27 Thread Ian Clelland
On Mon, Feb 27, 2012 at 1:36 PM, nicolas HERSOG <n.her...@gmail.com> wrote:

> Fun fact, I tried the command manage.py compilemessages, it takes
> loong time to finish and parse all of my workspace in order to create
> translation file xD.
> All my home except my project :| ...
>
>
Does your INSTALLED_APPS setting contain the apps that should be translated?

-- 
Regards,
Ian Clelland
<clell...@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: Using query set in views.py

2012-02-26 Thread Ian Clelland
On Sunday, February 26, 2012, Stanwin Siow wrote:

> Ok disregard my previous question.
>
> Here's the latest one.
>
>
> I have the following form in my HTML:
> * *
> * Keyword: *
> * *
>

Your immediate problem here is that your  element has an id, but no
name attribute. That is why you are getting None when you try to retrieve
it from the POST dictionary -- the browser never sent it to the server.

I'm certain that you have additional issues with your view function, but
this is the reason for the error that you are seeing right now.

Ian




> * *
> * *
> * *
>
> when the user presses the submit button, it will go to the method
> keyword_subscribe in views.py
>
>
> The method is as shown:
>
> *def keyword_subscribe(request):*
> *if request.POST:*
> * username = UserProfile.objects.all()*
> * #userid = username.objects.all()*
> *subscription_days = "7"*
> * new_keyword = request.POST.get('myTextField')*
> * print new_keyword*
> *new_keyword_subscribed =
> subscribe_keyword(username,subscription_days,new_keyword)*
> **
> *response = simplejson.dumps({'new_keyword':
> new_keyword_subscribed})   *
> * print new_keyword_subscribed  *
> *else:*
> *   # html = form.errors.as_ul()*
> *response = simplejson.dumps({'success':'False'})*
> * return HttpResponseRedirect("/accounts/login/")*
> *#if request.is_ajax():*
> * #   return HttpResponse(response, mimetype='application/json')*
> *#else:*
> * #   return HttpResponseRedirect("/")*
>
> Once in this method, i'm supposed to extract the word which the user
> entered in the textfield and store it in a variable called new_keyword
>
> However, i've been getting NONE which means there's something wrong
> somewhere and i do hope someone can help me.
>
> In addition, i would like to get the username which is stored in the
> UserProfile table in my database to be passed as a parameter to the next
> function too.
>
> How then do i implement the queryset needed?
>
> This should be clearer.
>
> Thank you.
>
>
> Best Regards,
>
> Stanwin Siow
>
>
>
> On Feb 26, 2012, at 6:25 PM, Daniel Roseman wrote:
>
> Your question is not at all clear. You can use whatever you like in your
> view. What problem are you having?
> --
> DR.
>
> --
> 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/-/1N2Cz2nv9wQJ.
> To post to this group, send email to 
> django-users@googlegroups.com<javascript:_e({}, 'cvml', 
> 'django-users@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com <javascript:_e({}, 'cvml',
> '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<javascript:_e({}, 'cvml', 
> 'django-users@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com <javascript:_e({}, 'cvml',
> 'django-users%2bunsubscr...@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>


-- 
Regards,
Ian Clelland
<clell...@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: internationalization makemessage don't work

2012-02-26 Thread Ian Clelland
On Sunday, February 26, 2012, nicolas HERSOG wrote:

> Hi folks !
>
> I'm trying for hours to internationalize my django website.
>
> I added to my settings.py this few lines :
>
> TIME_ZONE = 'Europe/Paris'
> LANGUAGE_CODE = 'fr-FR'
>
> I added to all templates i want to translate the tag trans for the
> sentence I want to  internationalize exemple :
>
> {% trans "article écrit :"%}
> {% trans "Nom :"%}
>
> And then at my root project i run django-admin.py makemessages -l en


Why are you running django-admin.py, rather than manage.py? manage.py knows
how to fund your settings files, and import all of your apps and check all
of your template dirs.

Try first running "manage.py makemessages -l fr" (since I suspect that your
site is already in French, you won't have to actually do anything with that
po file right now, but it's good to have)

Ian


> This command created a django.po file which contains the translations key
> for django debug tool bar, but none key of my webapp.
>
> Did I do something wrong, or miss something ?
>
> Thank you :)
>
> Nicolas
>
>
>
>  --
> 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<javascript:_e({}, 'cvml', 
> 'django-users@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com <javascript:_e({}, 'cvml',
> 'django-users%2bunsubscr...@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>


-- 
Regards,
Ian Clelland
<clell...@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 1.1: nonexistent URLs display 500.html instead of 404.html

2012-02-22 Thread Ian Clelland
On Tue, Feb 21, 2012 at 5:33 PM, rabousha <ramiaboushaw...@gmail.com> wrote:

> Yes, only for TEMPLATE_CONTEXT_PROCESSORS, the commas aren't added by
> default after the strings. I suspect it's an old bug.
>
> TEMPLATE_CONTEXT_PROCESSORS = (
>'django.core.context_processors.auth'
>'django.core.context_processors.debug'
>'django.core.context_processors.i18n'
>'django.core.context_processors.media'
> )
>

Interesting... my mistake for thinking that this was a syntax error -- this
is equivalent to the declaration

TEMPLATE_CONTEXT_PROCESSORS = (

'django.core.context_processors.authdjango.core.context_processors.debugdjango.core.context_processors.i18ndjango.core.context_processors.media'
)

since the Python interpreter will concatenate string literals.

Either way, this should raise an error -- an ImproperlyConfiguredError, to
be precise. I don't know of any bugs in Django 1.1 that would cause this to
raise a 404 instead -- there is likely a problem with your particular
settings.

I'm pretty sure that, even if there was a legitimate bug here, it would not
get fixed. The last update to the 1.1 series was over a year ago, and even
at that time, only security-related issues were being addressed.

If this is a serious issue for you (and it shouldn't be, if the 'fix' is to
correct the errors in your settings.py), then the recommended solution is
almost certainly going to be to upgrade. Django 1.3 is almost a year old,
and is still the current version -- if you can wait a couple of weeks,
you'll see 1.4 released as well.


> With the commas missing, all requests to nonexistent URLs returned a
> 500 error.
>
>
> On Feb 22, 12:31 am, Ian Clelland <clell...@gmail.com> wrote:
> > By 'missing commas', do you mean that there are *syntax errors* in your
> > settings.py file?
> >
> > That will definitely cause a 500 error, and I would be surprised if it
> > didn't do it on *every* request.
> > It seems odd that you would get a 404 when Debug is turned on, but that
> may
> > be related to the handling of the 500 error template, or possibly
> indicates
> > another error in your application settings.
> >
> > Ian
> >
> > On Tue, Feb 21, 2012 at 10:36 AM, rabousha <ramiaboushaw...@gmail.com
> >wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > I am using django 1.1, with DEBUG = False, and
> > > TEMPLATE_CONTEXT_PROCESSORS is missing commas, all nonexistent URLs
> > > display 500.html instead of 404.html. If I set DEBUG to True, it
> > > displays the default 404 page. if I add the commas to
> > > TEMPLATE_CONTEXT_PROCESSORS, then it displays the 404 page. The commas
> > > are not added by default. All pages do exist, so I am not missing
> > > anything.
> >
> > > Is this a known bug?
> >
> > > --
> > > 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.
> >
> > --
> > Regards,
> > Ian Clelland
> > <clell...@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.
>
>


-- 
Regards,
Ian Clelland
<clell...@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 1.1: nonexistent URLs display 500.html instead of 404.html

2012-02-21 Thread Ian Clelland
By 'missing commas', do you mean that there are *syntax errors* in your
settings.py file?

That will definitely cause a 500 error, and I would be surprised if it
didn't do it on *every* request.
It seems odd that you would get a 404 when Debug is turned on, but that may
be related to the handling of the 500 error template, or possibly indicates
another error in your application settings.

Ian

On Tue, Feb 21, 2012 at 10:36 AM, rabousha <ramiaboushaw...@gmail.com>wrote:

> I am using django 1.1, with DEBUG = False, and
> TEMPLATE_CONTEXT_PROCESSORS is missing commas, all nonexistent URLs
> display 500.html instead of 404.html. If I set DEBUG to True, it
> displays the default 404 page. if I add the commas to
> TEMPLATE_CONTEXT_PROCESSORS, then it displays the 404 page. The commas
> are not added by default. All pages do exist, so I am not missing
> anything.
>
> Is this a known bug?
>
> --
> 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.
>
>


-- 
Regards,
Ian Clelland
<clell...@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: saving in a view

2012-01-27 Thread Ian Clelland
On Fri, Jan 27, 2012 at 9:26 AM, MikeKJ <mike.jo...@paston.co.uk> wrote:

> I have 2 models Count is purely an incremental counter a model called Sale,
> the reason for the Count models is to increment a reference for Sale and
> other models
>
> In a view I get the latest sale and count then I want to save the
> incemented
> count (number) to Count also save number to Sale
>
>
First off, the instances of "0" at the end of the first two lines should be
[0] (surrounded by square brackets), but I'm assuming that that's an
artifact of the email transport.

Past that, your code doesn't actually *do* anything, other than pull two
objects out of the database, and save them again, unmodified. Let's look at
the method you've pasted, line by line:

customer
> = Sale.objects.all().order_by('-id').filter(email_address=email).distinct()[0]
> this = Count.objects.all().order_by('-id')[0]


This part retrieves two objects from the database. You may want to guard
these two lines with an exception handler -- if there are no matching Sale
objects, or if the Count table is empty, either of these lines could raise
a KeyError.

number = this.number + 1


This line creates a new local variable called number, and assigns it the
value of this.number + 1. It doesn't do anything to the 'this' object at
all.

a = this.save(force_insert=True)


So this line forces 'this' to be re-saved (remember, though, that it hasn't
been modified, so the save doesn't really do anything). Model.save()
doesn't return anything, so 'a' is assigned the value None.

ref = number
> reference = number
> name = customer.name
> salutation = customer.salutation


Again, these just create some new local variables, but they don't actually
change your customer object at all, so this line:

b = customer.save(force_update=True)


Just forces a re-save of the unmodified customer object.

I"m not sure exactly what it is that you're trying to do with this view,
but I think that you are going to need some lines that actually update the
'this' and 'customer' object. You would do that like this:

this.number = this.number + 1

or
customer.reference = number

Then, when you save the objects (and just use "customer.save()", the
force_update=True isn't really necessary), then the new values you have
assigned will be saved in the database.

-- 
Regards,
Ian Clelland
<clell...@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: Please help with complex aggregation/annotation issue

2012-01-19 Thread Ian Clelland
On Wed, Jan 18, 2012 at 1:03 AM, Salvatore Iovene <
salvatore.iov...@gmail.com> wrote:

> Hi,
> I apologize for the lousy title, but I really didn't know how to summarize
> the problem I'm facing. I have the following model:
>
> class MessierMarathon(models.Model):
> messier_number = models.IntegerField()
> image = models.ForeignKey(Image)
> nominations = models.IntegerField(default = 0)
> nominators = models.ManyToManyField(User, null=True)
>
> def __unicode__(self):
> return 'M %i' % self.messier_number
>
> class Meta:
> unique_together = ('messier_number', 'image')
> ordering = ('messier_number', 'nominations')
>
>
> A typical content for this model would be:
>
>Image A: 5 nominations for messier_number 1
>Image B: 4 nominations for messier_number 1
>Image C: 6 nominations for messier_number 2
>...and so on.
>
> I would like to formulate a query that returns me one image for each
> messier_number, picking the one with the most nominations. So, in the
> previous example, the query would return images A and C. The image B would
> not be returned because image A has more nominations for messier_number 1.
>
> The images returned must be sorted by messier_number, and of course may
> repeat. (An image might contain more that one Messier object, and get
> highest nomination counts for both).
>


The other edge case that you need to consider (and this is the one that
makes this more than a simple aggregation query) -- what should be returned
if two images have the same number of nominations for a given
messier_number? Are both of them returned, or is there another tie-breaking
criterion?

It's easy to get the highest nomination count for each messier number:


MessierMarathon.objects.values('messier_number').annotate(Max('nominations'))

What is harder is getting a unique image attached to each messier_number,
given that value for nominations.

A simple solution, which unfortunately requires a database hit for each
messier_number, would be:

highest_counts =
MessierMarathon.objects.values('messier_number').annotate(Max('nominations'))
top_images = dict((x['messier_number'],
MessierMarathon.objects.filter(messier_number=x['messier_number'],
nominations=x['nominations'])[0].image) for x in highest_counts)

You might be better off writing raw SQL for it, though; you could probably
get it all with one (convoluted) query.

-- 
Regards,
Ian Clelland
<clell...@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 orm and no primary key

2012-01-10 Thread Ian Clelland
On Tue, Jan 10, 2012 at 9:04 AM, webonomic <webono...@gmail.com> wrote:

> The Django Book alludes to this, and maybe the comments there will
> help you.
>
> Go to http://www.djangobook.com/en/1.0/chapter05/
> and search for this paragraph:
>
> "Finally, note we haven’t explicitly defined a primary key in any of
> these models. Unless you instruct it otherwise, Django automatically
> gives every model an auto-incrementing integer primary key field
> called id. Each Django model is required to have a single-column
> primary key."
>

This is referring to an implicit primary key, which Django will create if
you do not specify one. The question was regarding using an existing table
with no PK in Django.

> I am wondering if it is possible to still use the django orm without
> > having a primary key at all, I currently got a table holding 61 million
> > entries soon gonna expand to hold 600 million entries, that table never
> > need to identify one entry alone its only to pull off statistics based
> > on other fields, so far I  dropped the primary key index in the database
> > and all works fine, but I know the orm always want a primary key, would
> > it still work if I for example claim one of the fields which aren't
> > unique as the primary key?
> >
> > Or is the only way to do it, use the cursor or even mysqldb directly?
>

This is possible -- there was some discussion on this list about it just a
few days ago. If you tell Django that another field is the actual primary
key, then it will not assume that there is an 'id' column (which is good,
because otherwise it will try to include that in any SELECT statements that
it issues).

As long as you consider this table to be essentially read-only, and you
don't try to use the ORM to create any records in it, then you shouldn't
have any problems with this. As specific measures:

- Don't try to create records with Model.objects.create() or
Model.objects.get_or_create()
- If you have to retrieve records, use filter() rather than get, if you
can't ever assume uniqueness
- Similarly, if you have to update records, use update() rather than save().

It sounds like you want to use aggregate queries on this table anyway, so
you (hopefully) shouldn't run into any issues.

Oh, and don't register this model with the admin; most of that framework is
built around the idea of rows uniquely addressable by their primary key.

-- 
Regards,
Ian Clelland
<clell...@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: Can I escape or delimit the "{{ }}" template braces?

2011-12-19 Thread Ian Clelland
On Monday, December 19, 2011, J. Marc Edwards <
marc.edwa...@nimbisservices.com> wrote:
> I'd like to write a paragraph on my page that describes the {{ }} syntax,
but the template interpreter is interpreting the braces.

I think what you need is the {% templatetag %} tag -- it outputs template
tag start and end markers.

https://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs#templatetag

It can get a bit wordy, though, if your page has a lot of tags on it. If
you search online, you will find that a number of people have written {%
verbatim %} tags to solve just this problem.

-- 
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 1.2.1 strange problem

2011-12-15 Thread Ian Clelland
On Thu, Dec 15, 2011 at 5:56 AM, Sells, Fred
<fred.se...@adventistcare.org>wrote:

> I’ve got an older app that’s been running in production for about 2 years
> on RedHat 4, MySQL 5.0.77 with MyISAM tables, Django 1.2.1 and Python 2.4.
> 
>
> ** **
>
> This app is used heavily by internal users, which is a relatively light
> load compared to public sites.  I actually use Flex for the client side and
> save each field when the user changes it.
>
> ** **
>
> About once a month one field in particular will have its value cleared, or
> perhaps the save operation did not complete before the next user input hits
> the server.  I’ve searched my code for an unexpected reference to this
> field name with no results.  As I understand it, Django is single threaded
> so I don’t know how this can happen.
>

The Django code itself is not multithreaded -- it spawns no threads of its
own -- but that doesn't mean that your setup is single-threaded. That
depends entirely on how your web server is configured. Every production
environment I have seen uses processes or threads to serve multiple
requests simultaneously, which means that multiple instances of the Django
code are running at any given time.

Django tries to be thread-safe, which is slightly different -- the code is
written such that multiple threads can co-exist without stomping all over
each other's data, at least at the Python level.

At the database level, things are different again. This is probably where
your problems are coming from. If your database doesn't support isolation
through transactions (if you're using MyISAM tables on MySQL, basically),
then you are susceptible to problems like this. Database operations can and
will be interleaved, depending on when and how your web server decides to
schedule its threads.


> 
>
> ** **
>
> Has anyone seen similar behavior?  I plan to upgrade next month anyway,
> but could this be an artifact of the older Django or of MyISAM tables?
>

I doubt that upgrading Django will solve anything, but I would recommend
upgrading your tables to InnoDB. The only reasons I know for sticking with
MyISAM are a requirement for speed over all else (including data
integrity), and to use the MySQL "full-text-search" feature.

  I’m not using transactions since I’m not an experienced DBA, but should I?
>

Happily, Django will take care of all of this for you; you don't have to be
a DBA, or even think about transactions most of the time. As long as your
database supports it, Django will automatically isolate each request in its
own transaction. If the view returns a response, the transaction will be
committed to the database, and if the view raises error, the transaction
will be rolled back automatically. In almost every case, this behaviour
will be exactly what you want.


-- 
Regards,
Ian Clelland
<clell...@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: Can a template extend a template?

2011-12-13 Thread Ian Clelland
On Tue, Dec 13, 2011 at 2:21 PM, Jason <1jason.whatf...@gmail.com> wrote:

> Hi there,
>
> I love the concept of DRY, and django's enthusiasm for this concept. In
> light of this I have tried to have a template extend a template, but it
> doesn't seem to work. Is there a better way than what I'm currently doing?
>
> The current way
>
> index.html
>
> {% if current_user %}
> {% extends "_logged_out_template.html" %}
>
> {% else %}
> {% extends "_logged_in_template.html" %}
> {% endif %}
>
> contact.html
>
> {% if current_user %}
>
> {% extends "_logged_out_template.html" %}
>
> {% else %}
>
> {% extends "_logged_in_template.html" %}
>
> {% endif %}
>
>
>
> The way I would like it to be (but it didn't work)
>
> index.html
> {% extends "_base_template.html" %}
>
> _base_script.html
>
> {% if current_user %}
>
> {% extends "_logged_out_template.html" %}
>
> {% else %}
>
> {% extends "_logged_in_template.html" %}
>
> {% endif %}
>
>  --
> 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/-/8j1xs23yjnAJ.
> 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.
>


Honestly, I never even realized that you *could* put an {% extends %} node
inside of an {% if %} node like that.

What I find works, if you really do have to dynamically change the base
template that you are inheriting from, is to set a context variable in your
view, and use it in the template. Nobody ever said that the argument to
'extends' has to be a literal string:

View:
def my_view(request):
if request.user.is_authenticated:
base_template = "_logged_in_template.html"
else:
base_template = "_logged_out_template.html"

   ...
   return render("my_template.html", RequestContext({"base_template":
base_template...}))


Template: (my_template.html)

{% extends base_template %}


(In a real app, I would use a base class for the view which would set the
base template for every request automatically, or I would do it in a
context processor, rather than putting those four lines at the top of every
single view)


-- 
Regards,
Ian Clelland
<clell...@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: Query with no-correspondence results

2011-12-08 Thread Ian Clelland
On Thu, Dec 8, 2011 at 12:45 PM, wgis <alpha.sh...@gmail.com> wrote:

> Ian Clelland, it worked! Thanks a lot for your perseverance
>
> Tom's secret sauce it's not working, unfortunately =(
> Just (Carrots, Flavour, 3.0)
> I guess since some 'contexts' don't have an associated thing-vote, the
> filter will cut them off.
> It would be more neat with the ORM, but I must be looking for a golden
> a pot.
>
> Don't want to seem ungrateful but I realized that I should have not
> just an individual vote by context but also an average vote by
> context. Can you still pull it of? I'm sorry, I know it's not django
> anymore but I have to ask.
>

I would give this a shot:

select thing, name, avg(vote) from mydatabase_votecontext left
join mydatabase_vote on (mydatabase_vote.context_id =
mydatabase_votecontext.id and thing='Carrots') group by thing, name;

Ian

Thanks for your help.
>
> --
> 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.
>
>


-- 
Regards,
Ian Clelland
<clell...@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 E-Commerce Framework

2011-12-08 Thread Ian Clelland
On Wednesday, December 7, 2011, bobhaugen <bob.hau...@gmail.com> wrote:
> I'm guessing that the OP wanted to develop a "standard" e-commerce
> site for a single company, in which case I agree with Stuart and Andre
> that the way to go is a well-tested e-commerce framework.
>
> I had to roll my own because I was doing something very different: B2B
> e-commerce with an efficient order form (order from a grid combining
> many products, not one-product-per-page adding to a shopping cart one
> at a time) and order line items from many producers where the payment
> from the customer needs to get allocated to each producer.  But had a
> well-tested framework for that kind of thing been available, I would
> have grabbed it.

I think the OP's phrase "e-commerce framework" is a bit vague, as well --
there are a lot of different components that could all get tagged with that
label: payment processing, recurring billing, shopping cart, fulfillment,
inventory management -- it's probably not too much of a stretch for some
people to add accounting and customer service to that list, too.

You say you had to roll your own, but really you just didn't need the
shopping cart functionality. Even with your requirements, I'm sure you are
better off using a well-tested payment gateway rather than writing your own
interface to Paypal.

At some level, everybody is going to have to do *some* customization;
whether that's just overriding some templates, or building the whole site
down to the payment provider interface. We could probably provide a survey
of all related packages in this thread, but the OP might also have to do
some more thinking about what their actual requirements are.

The good thing is that the Django community has build lots of high-quality
modules that cover just about every corner of this space, so any specific
needs can almost certainly be addresses here. "What can I use for
e-commerce" is a very open-ended question, though.


>
> As it is, I did use django-paypal with some customizations, which is
> its own kind of pain in the butt.  (Not django-paypal, the
> customizations, because now I am stuck with the version of django-
> paypal that I customized...)  Eventually I'll take another look at
> payment apps and some of the newer e-commerce frameworks that are more
> modular.
>
> --
> 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.
>
>

-- 
Regards,
Ian Clelland
<clell...@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 E-Commerce Framework

2011-12-08 Thread Ian Clelland
On Wednesday, December 7, 2011, bobhaugen <bob.hau...@gmail.com> wrote:
> I'm guessing that the OP wanted to develop a "standard" e-commerce
> site for a single company, in which case I agree with Stuart and Andre
> that the way to go is a well-tested e-commerce framework.
>
> I had to roll my own because I was doing something very different: B2B
> e-commerce with an efficient order form (order from a grid combining
> many products, not one-product-per-page adding to a shopping cart one
> at a time) and order line items from many producers where the payment
> from the customer needs to get allocated to each producer.  But had a
> well-tested framework for that kind of thing been available, I would
> have grabbed it.

I think the OP's phrase "e-commerce framework" is a bit vague, as well --
there are a lot of different components that could all get tagged with that
label: payment processing, recurring billing, shopping cart, fulfillment,
inventory management -- it's probably not too much of a stretch for some
people to add accounting and customer service to that list, too.

You say you had to roll your own, but really you just didn't need the
shopping cart functionality. Even with your requirements, I'm sure you are
better off using a well-tested payment gateway rather than writing your own
interface to Paypal.

At some level, everybody is going to have to do *some* customization;
whether that's just overriding some templates, or building the whole site
down to the payment provider interface. We could probably provide a survey
of all related packages in this thread, but the OP might also have to do
some more thinking about what their actual requirements are.

The good thing is that the Django community has build lots of high-quality
modules that cover just about every corner of this space, so any specific
needs can almost certainly be addresses here. "What can I use for
e-commerce" is a very open-ended question, though.


>
> As it is, I did use django-paypal with some customizations, which is
> its own kind of pain in the butt.  (Not django-paypal, the
> customizations, because now I am stuck with the version of django-
> paypal that I customized...)  Eventually I'll take another look at
> payment apps and some of the newer e-commerce frameworks that are more
> modular.
>
> --
> 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.
>
>

-- 
Regards,
Ian Clelland
<clell...@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: Query with no-correspondence results

2011-12-07 Thread Ian Clelland
On Wed, Dec 7, 2011 at 7:54 AM, wgis <alpha.sh...@gmail.com> wrote:

> First, thank you both for your answers. I'm now realizing that doing
> this with the ORM is not so easy as I thought it would be to others
> django fellows (it's my first django project, but I'm nailing it =P).
> I saw your RAW SQL solution and it looked genius-simple. I have short
> experience with the JOIN operation but that make sense to me. Yet, I
> tested, and I still get
> (Carrot, Flavour, 2.0)
> and just
> (Cars, Smell, 4.2) (Cars, Usability, 4.9)without the other contexts.
> If I remove the WHEREs (not filtering by user or thing), it still
> presents without nulls (or 0.0)
> Is there other way you can see?
> Again, thanks
> On 6 Dez, 21:48, Ian Clelland <clell...@gmail.com> wrote:
> > On Tue, Dec 6, 2011 at 1:35 PM, Reinout van Rees <rein...@vanrees.org
> >wrote:
> >
> > > Ah! Now I get your point. You also want the "empty" results for which
> > > there's no SQL data. Sorry, but I don't see a way in which you can do
> that
> > > with an SQL query (and so also not with a Django query).
> >
> > > In case you want all contexts, you'll have to query for those
> > > specifically. And afterwards grab the results belonging to that
> context. So
> > > you won't escape a for loop and some manual work, I'm afraid.
> >
> > Raw SQL:
> > select thing, name, vote from mydatabase_votecontext left join
> > mydatabase_vote on (mydatabase_vote.context_id =
> mydatabase_votecontext.id)
> > where thing='Carrot' and user='Me'
> >
> > That should return null if there is no vote. If you'd rather have zeros,
> > then use this:
> >
> > select thing, name, ifnull(vote, 0.0) from mydatabase_votecontext left
> join
> > mydatabase_vote on (mydatabase_vote.context_id =
> mydatabase_votecontext.id)
> > where thing='Carrot' and user='Me'
> >
> > There still might be a way to do it with the ORM; but you can definitely
> > use raw sql for this.
> >
> > --
> > Regards,
> > Ian Clelland
> > <clell...@gmail.com>
>
>
You're right -- it's the 'and user='Me' bit that is messing it up. I know
you left the id columns out to simplify the problem, but without a full
table structure, it's harder for me to visualize the join and the rows that
are getting selected.

Try this:
select thing, name, vote from mydatabase_votecontext left
join mydatabase_vote on (mydatabase_vote.context_id =
mydatabase_votecontext.id and thing='Carrots' and user='me')

With that statement, the left join should produce:
(votecontext.id, name, vote.id, thing, context_id, user, vote)
(1, Flavour, 4, Carrots, 1, Me, 3.0)
(2, Smell, NULL, NULL, NULL, NULL)
(3, Usability, NULL, NULL, NULL, NULL)
(4, Size, NULL, NULL, NULL, NULL)

And the select columns should reduce the width, to this:
(thing, name, vote)
(Carrots, Flavour, 3.0)
(NULL, Smell, NULL)
(NULL, Usability, NULL)
(NULL, Size, NULL)

If you absolutely need 'Carrots' in the first column (and you might not;
you should have it in the template context anyway, when you need to display
it), then you would have to duplicate it in the query, and use another
ifnull, like this:

select ifnull(thing, 'Carrots'), name, vote from mydatabase_votecontext
left join mydatabase_vote on (mydatabase_vote.context_id =
mydatabase_votecontext.id and thing='Carrots' and user='me')

(Or try Tom's secret sauce, and see if that works :) )


-- 
Regards,
Ian Clelland
<clell...@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: Query with no-correspondence results

2011-12-06 Thread Ian Clelland
On Tue, Dec 6, 2011 at 1:35 PM, Reinout van Rees <rein...@vanrees.org>wrote:

> Ah! Now I get your point. You also want the "empty" results for which
> there's no SQL data. Sorry, but I don't see a way in which you can do that
> with an SQL query (and so also not with a Django query).
>
> In case you want all contexts, you'll have to query for those
> specifically. And afterwards grab the results belonging to that context. So
> you won't escape a for loop and some manual work, I'm afraid.
>
>
Raw SQL:
select thing, name, vote from mydatabase_votecontext left join
mydatabase_vote on (mydatabase_vote.context_id = mydatabase_votecontext.id)
where thing='Carrot' and user='Me'

That should return null if there is no vote. If you'd rather have zeros,
then use this:

select thing, name, ifnull(vote, 0.0) from mydatabase_votecontext left join
mydatabase_vote on (mydatabase_vote.context_id = mydatabase_votecontext.id)
where thing='Carrot' and user='Me'

There still might be a way to do it with the ORM; but you can definitely
use raw sql for this.


-- 
Regards,
Ian Clelland
<clell...@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: models.Q raising exception

2011-12-01 Thread Ian Clelland
On Thu, Dec 1, 2011 at 12:58 PM, Martin Tiršel <dja...@blackpage.eu> wrote:

> Hello,
>
> why this is not working?
>
> from django.db import models
>
> ...
>GameProfile.objects.get(
>models.Q(nick=nick) | models.Q(user=self.user),
>world=self.world,
>)
>
>
A shot in the dark here, but if you are getting "'module' object has no
attribute 'Q'" here, have you imported something else called 'models'? Or
redefined it somehow above this code?

Try:
from django.db import models as django_models
...
GameProfile.objects.get(
   django_models.Q(nick=nick) | django_models.Q(user=self.user),
   world=self.world,
   )

to see if the problem goes away. If it does, it's almost definitely a
redefined name.

-- 
Regards,
Ian Clelland
<clell...@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: unit tests and 'system' tests with history

2011-11-30 Thread Ian Clelland
On Wed, Nov 30, 2011 at 2:48 AM, Gelonida N <gelon...@gmail.com> wrote:

> 2.) Stress / System tests
> --
>

These are often called 'integration tests', and are used to test whether
all of the (properly unit-tested) components of the system actually
function properly when assembled together.


>
> I'd also like to do some other tests, where I work on a system and where
> I am able to suffer from my history.
>
> Example (the example is perhaps too simple to see what I'm aiming it)
> - I create an entry
> - I rename an entry
> - I remove an entry
>
> If I had three independent tests I would never find out if I had a weird
> bug, which would make the system fail if I tried to remove an entry
> which has been renamed before.
>

As an aside, I'm not sure that I would use this sort of test framework for
these kinds of bugs -- there are just too many ways for the system to fail
if you start thinking this way:

   - What if it only fails when the entry has been renamed?
   - What if it only fails when the entry has been renamed to something
   longer?
   - What if it only fails when the entry has been renamed while someone
   else was editing it?
   - What if it only fails when the entry has a name with no vowels in it,
   which was also used as another user's password, but not in the last six
   weeks? :)

You can only simulate so many conditions, and lots of bugs can lurk
undetected even with a whole suite of such tests. Even worse, if the code
changes, then the exact bug that you were testing for might appear to be
fixed, but actually changes very slightly, and doesn't get picked up any
more.

In a case like this, I would normally wait to find out that there was a
problem in the first place, and then institute a 'regression test' --
figure out the cause of the original bug (say, renaming the entry put the
record into an inconsistent state) and then set up a test which:

   1. instantiates a correct record directly
   2. performs the rename operation that was failing
   3. checks that the record is still consistent under every constraint.

And I would do all of these at the lowest level that makes sense --
certainly not by starting at the HTTP level.


> What would be a recommended way to run such system tests?
>
> 'just create a unit test, which is just calling sunb tests explicitely
> in the required order?)
>

For integration testing, that's exactly what I do -- set up a unit test
(not really a unit test in this case, but it's a subclass of
unittest.TestCase) that uses the django test client to perform a small
sequence of operations; usually a GET, checking the returned context, and
then a POST, checking the return status (200 for form errors; 30x for
successful redirects). I will set up any required objects in the database
first (in fixtures, setUp or the test method itself), and test them
afterwards.

Usually there aren't too many of these tests, though -- just enough that I
know that the GET and POST methods are not failing spectacularly. The
actual logic is tested with a bunch of much faster unit tests.


> As part of these system tests I would like to add some of my unit tests,
> but such, that the data base is NOT reset after each test run.
>

As a rule, I find it makes much more sense to declare the state of the
database before each test, and then just test a few operations. As long as
you properly test the consistency of the data after each operation, then
you shouldn't run into the "cascading failures" that you can get if each
test is dependent on the ones before it (or worse, cascading successes, if
one bug cancels out the effects of the another)

If you're actually looking for stress-testing, then there are a number of
other frameworks for that (ab, Bees with Machine Guns, etc) that will tell
you how your site performs under load. Host-based testing should be there
to tell you that your site behaves predictably and correctly under normal
operation.

Ian


>
>
> As you can see from my previous questions I'm used to 'non-atomic'
> testing (This was for systems which needed a very huge startup time
> and where taking snapshots was virtually impossible)
>
> Thus I often combined unit tests / system tests.
>
> These stress tests shall be able to run for several hours / days,
> whereas unit tests would run in a few minutes.
>
>
> Thanks for any suggestions
>
>
> --
> 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.
>
>


-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this mess

Re: Retrieve object model admin userid & password?

2011-11-30 Thread Ian Clelland
On Wed, Nov 30, 2011 at 10:22 AM, Tim Sawyer <list.dja...@calidris.co.uk>wrote:

> You can't retrieve the password, as that would be a security flaw.  The
> security works by hashing the password entered into the login form, and
> comparing the hashed version with the one stored on the database.  Hash
> functions are quick to run one way, but difficult to reverse, hence it's
> difficult to get back the password used.
>
> You can reset a users password in the admin site - login to admin, open
> the user up, then use the change password link next to the user's password
> field.
>
> This, of course, supposes that the password you've forgotten isn't the
> only admin password.  If it is, then you could delete the row from the
> auth_user database table and do a syncdb - that should prompt you to create
> a superuser, if I recall correctly.
>

Yes, yes and yes.

If you have console access, you can also do this:

manage.py changepassword username_goes_here

That will allow you to reset anybody's password; superuser or otherwise.

-- 
Regards,
Ian Clelland
<clell...@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: Boolean test on queryset

2011-11-28 Thread Ian Clelland
On Monday, November 28, 2011, Adam Nelson <a...@yipit.com> wrote:
> Jirka,
> That doesn't solve the problem.  That will still do a very expensive
count() operation on the queryset.  In fact, examples.count() is what
happens when you do bool(examples) anyway.

I'm confused here -- examples.count() is definitely not the same as
examples.__len__(), which is what you originally claimed that bool() was
doing. examples.count() should issue a SELECT COUNT query, while len()
iterates through the rows in the result set.

If you just need to know whether at least one row exists in the result, use
examples.exists() -- that's what it's for.

https://docs.djangoproject.com/en/1.3/ref/models/querysets/#exists

>From the (linked) docs:

> Returns True if the QuerySet contains any results, and False if not. This
tries to perform the query in the simplest and fastest way possible, but it
does execute nearly the same query. This means that calling
QuerySet.exists() is faster than bool(some_query_set), but not by a large
degree.


> Thanks,
> Adam
>
> On Mon, Nov 28, 2011 at 8:11 PM, Jirka Vejrazka <jirka.vejra...@gmail.com>
wrote:
>>
>> Hi Adam,
>>
>>  I tend to use:
>>
>>  if examples.count():
>>
>>...something...
>>
>>  HTH
>>
>>Jirka
>>
>> --
>> 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.
>

-- 
Regards,
Ian Clelland
<clell...@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.conf.urls import question

2011-11-28 Thread Ian Clelland
On Fri, Nov 25, 2011 at 6:39 PM, Chet <ccor...@gmail.com> wrote:

> Hello,
>
> I just finished to tutorial and for in both my urls.py files, if I
> use:
>
> from django.conf.urls import patterns, include, url
>
> I get an http500 error: TemplateDoesNotExist: 500.html
>

This message is from Django, trying to tell you that there is a
configuration error, but it can't display that error to you because it is
missing the template for the "500" server error page. (Do you have DEBUG
disabled in your settings? Set it to True, and Django should use its
built-in technical error page, which will show you all of the details of
the underlying error.)

The error itself is very likely an import error, because that line in your
urls.py shouldn't work. Specifically, 'patterns', 'include', and 'url'
aren't defined directly inside of the django.conf.urls module, but as part
of django.conf.urls.defaults. (at least, until Django 1.4)

>
> before I had it as:
>
> from django.conf.urls.defaults import patterns, include, url
>

This line is correct for all released versions of Django.

>
> and when I change this statement to be default, everything works fine.
> I don't know why. In the tutorial it says to do it the first way
>
>
What Django version are you using to run through the tutorial?

It sounds to me like you are have a released version of Django (1.2, 1.3,
etc) installed, but you are following the tutorial for the development
version. (There used to be a big warning about this at the top of all every
page in the development docs, but it seems to have disappeared.)

Try following the tutorial starting at
https://docs.djangoproject.com/en/1.3/intro/tutorial01/
instead, and see how far you can get.


-- 
Regards,
Ian Clelland
<clell...@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: string indices must be integers, not str

2011-11-21 Thread Ian Clelland
On Mon, Nov 21, 2011 at 9:37 AM, MikeKJ <mike.jo...@paston.co.uk> wrote:

>
> Traceback
>
> string indices must be integers, not str
>
> Request Method: POST
> Request URL:http://newrutherford.paston2.webfactional.com/question/
> Django Version: 1.3.1
> Exception Type: TypeError
> Exception Value:
>
> string indices must be integers, not str
>
> Exception Location:
> /home/paston2/webapps/newrutherford/newrutherford/question/views.py in
> question, line 31
>

Line 31 is the problem --- and we can't tell which one is line 31 from the
code you've posted here.

This line looks wrong to me:

send_mail(settings.EMAIL_SUBJECT_PREFIX +"Email from the

question form", msg_header+msg_middle, settings.DEFAULT_FROM_EMAIL

[settings.CONTACT_EMAIL_TO], fail_silently=False)


Maybe it's a word-wrapping issue, but
"settings.DEFAULT_FROM_EMAIL[settings.CONTACT_EMAIL_TO]"
looks like you're trying to use a string to index into another string
variable.

Ian

-- 
Regards,
Ian Clelland
<clell...@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: Forbiden 403 error

2011-11-16 Thread Ian Clelland
On Wed, Nov 16, 2011 at 10:36 AM, Djano_newb <zamboni_...@yahoo.com> wrote:

>
> I am new to both python and Django but I have been programming for more
> than
> 20 years so I am teaching myself this stuff.  I came across an old training
> video that I have been going through.  This training has you develop a
> website that can create web pages.  I got everything right so far but I
> just
> got to the point where you are to save off your changes to create a new
> file
> and I am getting the 403 Forbidden error associated with a POST to my
> connection.  The error specifically states "CSRF token missing or
> incorrect."
>
>
It certainly does sound like your tutorial video is old; probably
pre-dating the built-in CSRF protection in Django.

The most relevant documentation is here:
https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/


> Now I am currently reading through this stuff on the Django web site and I
> find that you must have it at the top of your "views" but can someone
> explain in more plain language why this isn't on by default and what the
> problem really is here?  In reading the info on the Django site it seems
> backwards so I must be missing something.  When I read it, it sounds like
> you have to add this to "gain" the protection not remove it.  What I think
> I
> am seeing is my system is not allowing my browser to write new files so I
> have the protection by default and I need to add this stuff in order to
> remove the protection.  That makes sense to me but seems backwards from
> what
> I read on the Django site.  I am very confused by this.  Any help would be
> appreciated.
>

It certainly is quite confusing to say the the CSRF token has to go "at the
top of your views". Let me see if I can explain it better:

Django's CSRF protection is built-in; that is, it's on by default, and you,
as the site developer, have to specifically opt out to get around it (more
about that below). What you are seeing is the correct response to a form
submission that is missing the CSRF token. Any POST to your application
that doesn't include that token will be rejected, and Django will generate
a "403 Forbidden" error.

To get past these checks, you need to include the CSRF token in your forms.
The simplest way to do this is to include the template tag somewhere in
your HTML  element. (People seem to do it at the top, but it could go
anywhere). It's as simple as adding

{% csrf_token %}

in your template.

That tag will generate a hidden form element which will be submitted with
your form, and Django will accept the form submission and pass it along to
your view.

There are other, more complicated methods, if you are using JavaScript to
submit your forms, or if you need to access the actual token value, for
some reason, but this tag works for almost all cases.

Now, if you can't supply the token for some reason, and you need to opt out
(perhaps your code is part of an unauthenticated HTTP API, and you want to
accept POST requests from user agents that won't handle cookies), you can
use the @csrf_exempt decorator at the top of any of your views.

If you want to opt your whole application out of CSRF protection, then you
can do that too -- it's not baked into Django that deeply. You will need to
change your settings, and remove the CSRF middleware from
MIDDLEWARE_CLASSES. That will completely remove this feature from your
project. (and, of course, remove all of the security benefits that it comes
with)

Hope this helps,
Ian

-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: How can I serve static files while requiring Django-based access permissions?

2011-11-08 Thread Ian Clelland
On Tue, Nov 8, 2011 at 2:11 PM, zak2011 <zak2...@m.allo.ws> wrote:

> Dear Django Users,
>
> tl;dr: Please tell me what strategies I might use to serve a large
> static file from within Django, from views.py.
>
> If I want to limit access to a particular page in a Django app, I can
> do something like this in views.py:
>
> (Note: I will use four periods to indent, because spaces or tabs might
> not display properly.)
>
> def private_page(request):
> if special_permissions_checking_function(request.user):
> return render_to_response('private_page_template.html')
> else:
> return render_to_response('access_denied.html')
>
> What if I want to limit access to a large static file, instead of a
> dynamically generated HTML template?
>
>
The fastest way to do this is to tell the web server to serve the file from
a protected location. Apache and nginx both have ways to signal from python
code that a file should be read from disk and streamed to the user. This
file doesn't have to be in a location which is accessible through a normal
web request; ideally all access to it would be through your app, and you
can do whatever access checks that you want to before serving it.

Look up X-SENDFILE for Apache, or X-Accel-Redirect for nginx for the
details.

Ian


> Ideally the resulting website will be fast, but I also want to hear
> options that might be low performance.
>
> Thank you,
>
> Zak
>
> --
> 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.
>
>


-- 
Regards,
Ian Clelland
<clell...@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: QuerySet: "if obj in queryset" can be very slow

2011-11-02 Thread Ian Clelland
On Wed, Nov 2, 2011 at 10:46 AM, Tom Evans <tevans...@googlemail.com> wrote:

> OK, take this example. I have a django model table with 70 million
> rows in it. Doing any kind of query on this table is slow, and
> typically the query is date restrained - which mysql will use as the
> optimum key, meaning any further filtering is a table scan on the
> filtered rows.
>
> Pulling a large query (say, all logins in a month, ~1 million rows)
> takes only a few seconds longer than counting the number of rows the
> query would find - after all, the database still has to do precisely
> the same amount of work, it just doesn't have to deliver the data.
>
> Say I have a n entries I want to test are in that resultset, and I
> also want to iterate through the list, calculating some data and
> printing out the row, I can do the existence tests either in python or
> in the database. If I do it in the database, I have n+1 expensive
> queries to perform. If I do it in python, I have 1 expensive query to
> perform, and (worst case) n+1 full scans of the data retrieved (and I
> avoid locking the table for n+1 expensive queries).
>
> Depending on the size of the data set, as the developer I have the
> choice of which will be more appropriate for my needs. Sometimes I
> need "if qs.filter(pk=obj.pk).exists()", sometimes I need "if obj in
> qs".
>
>
Just looking at the source to QuerySet (finally), and it looks like the
__contains__ method actually does something different than this: It
evaluates the whole QuerySet in bulk at the database level, and starts
creating model instances based on that, but only until it finds a matching
one. So, after running "if obj in qs", you might end up with one object
created, or you might end up with 70M objects, or anywhere in between.

Again: odd, undocumented, and potentially surprising behaviour, and I'd
recommend explicit over implicit, especially in this case.



-- 
Regards,
Ian Clelland
<clell...@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: QuerySet: "if obj in queryset" can be very slow

2011-11-02 Thread Ian Clelland
On Wed, Nov 2, 2011 at 10:46 AM, Tom Evans <tevans...@googlemail.com> wrote:

> On Wed, Nov 2, 2011 at 5:30 PM, Ian Clelland <clell...@gmail.com> wrote:
> > On Wed, Nov 2, 2011 at 8:25 AM, Thomas Guettler <h...@tbz-pariv.de> wrote:
> >>
> >> # This is my current solution
> >> if get_special_objects().filter(pk=obj.pk).count():
> >># yes, it is special
> >>
> >
> > I can't speak to the "why" of this situation; it seems to me that this
> could
> > always be converted into a more efficient database query without any
> > unexpected side-effects (and if I really wanted the side effects, I would
> > just write "if obj in list(qs)" instead). In this case, though, I would
> > usually write something like this:
> > if get_special_objects().filter(pk=obj.pk).exists():
> ># yes, it is special
> > I believe that in some cases, the exists() query can be optimized to
> return
> > faster than a count() aggregation, and I think that the intent of the
> code
> > appears more clearly.
> > Ian
>
> OK, take this example. I have a django model table with 70 million
> rows in it. Doing any kind of query on this table is slow, and
> typically the query is date restrained - which mysql will use as the
> optimum key, meaning any further filtering is a table scan on the
> filtered rows.
>
> Pulling a large query (say, all logins in a month, ~1 million rows)
> takes only a few seconds longer than counting the number of rows the
> query would find - after all, the database still has to do precisely
> the same amount of work, it just doesn't have to deliver the data.
>
> Say I have a n entries I want to test are in that resultset, and I
> also want to iterate through the list, calculating some data and
> printing out the row, I can do the existence tests either in python or
> in the database. If I do it in the database, I have n+1 expensive
> queries to perform. If I do it in python, I have 1 expensive query to
> perform, and (worst case) n+1 full scans of the data retrieved (and I
> avoid locking the table for n+1 expensive queries).
>
> Depending on the size of the data set, as the developer I have the
> choice of which will be more appropriate for my needs. Sometimes I
> need "if qs.filter(pk=obj.pk).exists()", sometimes I need "if obj in
> qs".
>

I agree that there are situations where you want, or need, to pull the data
in to Python for processing, to avoid a lot of database overhead. That's
why we have select_related, as well: sometimes you really do need to just
grab as much as possible all at once.

The trouble is that querysets are *supposed* to be lazy; just evaluating as
much as necessary, as late as possible, to do the job. I think that this
behaviour violates the principle of least surprise, by instantiating a
(potentially very large) queryset as a side-effect of a simple inclusion
test.

Any other time that you want a queryset instantiated, the idiomatic way to
do it is to construct a Python list based on it:

# Get all objects at once from database
objs = list(qs)
# Now use that list multiple times in a method

or

for obj in list(qs):
  # qs is evaluated once, list members may be manipulated as needed in
Python

or, by extension,

if obj in list(qs):
  # stuff

I wouldn't rely on the behaviour of the in operator to evaluate the
queryset for me; it doesn't look right to me, it's not obvious to anyone
else looking at the code, and I don't think it's documented behaviour.

I would prefer that in did an exists query, but since there are explicit
ways to force either behavior, in practise I use one of those explicit
ways, rather than leave the code looking ambiguous.

-- 
Regards,
Ian Clelland
<clell...@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: QuerySet: "if obj in queryset" can be very slow

2011-11-02 Thread Ian Clelland
On Wed, Nov 2, 2011 at 8:25 AM, Thomas Guettler <h...@tbz-pariv.de> wrote:

> # This is my current solution
> if get_special_objects().filter(pk=obj.pk).count():
># yes, it is special
>
>
I can't speak to the "why" of this situation; it seems to me that this
could always be converted into a more efficient database query without any
unexpected side-effects (and if I really wanted the side effects, I would
just write "if obj in list(qs)" instead). In this case, though, I would
usually write something like this:

if get_special_objects().filter(pk=obj.pk).*exists*():
   # yes, it is special

I believe that in some cases, the exists() query can be optimized to return
faster than a count() aggregation, and I think that the intent of the code
appears more clearly.

Ian

-- 
Regards,
Ian Clelland
<clell...@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: Long usernames in auth_user?

2011-10-28 Thread Ian Clelland
On Wed, Oct 26, 2011 at 3:00 PM, Kurtis Mullins <kurtis.mull...@gmail.com>wrote:

> Check out userena as well. But a custom authentication back-end was the
> approach I originally took. And to answer your question, yes -- your chances
> of finding people w/ email addresses longer than 75 chars are less than
> finding people w/ 30 chars -- but still a limitation none-the-less as there
> is no limitation on how long an email address can be.
>
>
Not quite correct -- from RFC-3696:

   In addition to restrictions on syntax, there is a length limit on
   email addresses.  That limit is a maximum of 64 characters (octets)
   in the "local part" (before the "@") and a maximum of 255 characters
   (octets) in the domain part (after the "@") for a total length of 320
   characters.  Systems that handle email should be prepared to process
   addresses which are that long, even though they are rarely
   encountered.

320 characters suffices for any valid email address.


-- 
Regards,
Ian Clelland
<clell...@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: Database management commands

2011-10-28 Thread Ian Clelland
On Fri, Oct 28, 2011 at 2:35 AM, Daniele Procida <dani...@vurt.org> wrote:

> COuld it still be the case that the issue is the result of the older Django
> database having used one engine by default, and the new one the other?
>
>
That is possible -- in a MySQL shell, run "SHOW TABLE STATUS", and you can
see the engine used by all of your tables.


-- 
Regards,
Ian Clelland
<clell...@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: Using .filter() on a constant expression

2011-10-21 Thread Ian Clelland
On Sat, Oct 15, 2011 at 9:52 PM, Tim Chase
<django.us...@tim.thechases.com>wrote:

> I have some gnarly AND/OR logic combining Q() objects but deep
> within the logic, I need to do a comparison of two constants.  In an ideal
> world, the logic would look something like
>
>   def age(self, age):
> ... & Q(12=as_of.month) & ...
>
> but that's invalid python.
>
> I *can* break out this rats' nest of logic into individual
> queries, evaluate the constant expression, conditionally OR the
> logic into the tree, then reassemble all the parts.  However,
> that gets even uglier.

...

> Is there any way to include a constant comparison in a Q()?


Q objects are definitely not meant to handle that -- they have to operate on
some field in the database.

Besides, if you need to compare two constants, and you have both of them
available in python before you construct your query, then why would you want
to compare them in SQL? If the point is to include or exclude some other
conditions based on the calling parameters, then I would just use those
parameters to construct the right query to begin with.

I would think that breaking it into smaller, manageable pieces would make
the code easier to understand, rather than uglier, but that's a matter of
aesthetics, I suppose.

If you don't want to do that, then just use python to selectively include or
exclude the other Q objects (that you wanted to depend on your comparison):

Using your code as a base, I would do something like this: (I don't know if
this is correct; I get a headache trying to count all of the parentheses :)
)

 alive_q = use_as_of & (
# dob1 >= y1
Q(dob_year_min__gt=alive_y1) | (
Q(dob_year_min=alive_y1) & (
  Q(dob_month=None) |
  Q(dob_month__gt=as_of.month) | (
  Q(dob_month=as_of.month) & (
Q(dob_day=None) |
Q(dob_day__gte=as_of.day)
))
  )) | (

*# MAGIC HAPPENS HERE*
* ( Q(dob_month=1, dob_day=None) if as_of.month==12 else Q() )  |*
* ( Q(dob_day=1) if as_of_day==31 else Q())*
*# END MAGIC*

))
) & (
# dob2 < y2
Q(dob_year_max__lt=alive_y2) | (
Q(dob_year_max=alive_y2) & (
  Q(dob_month=None) |
  Q(dob_month__lt=as_of.month) | (
  Q(dob_month=as_of.month) & (
Q(dob_day=None) |
Q(dob_day__lt=as_of.day)
))
  )) | (
Q(dob_year_max=alive_y2+1) & (
  Q(dob_month=1) & (
Q(dob_day=None) |
Q(dob_day__lt=1)
  ))
 ))

-- 
Regards,
Ian Clelland
<clell...@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.db.models import Q help!

2011-10-21 Thread Ian Clelland
On Fri, Oct 21, 2011 at 11:06 AM, Kayode Odeyemi <drey...@gmail.com> wrote:

> Hello,
>
> Please I need help with django.db.models.Q. I have the query below which is
> returning empty
>
> qs =
> Q(financial_institution=request.user.get_profile().financial_institution)
> txn = Transaction.objects.extra(
> where=['(tpin=%s or teller_no=%s or identifier=%s) AND
> financial_institution_id=%s'],
> params=[value, str(value), value, str(qs)])
>
> If I substitute the line params=[value, str(value), value, str(qs)]) with
> params=[value, str(value), value, 1),
> I get real results from the database, meaning the problem lies with Q.
>
>
Why are you trying to use a Q object for this? Q objects are meant to be
passed into .filter(), not coerced into extra SQL.

If what you need for the params is the ID of another object, then just use
that!

Try something like

fi = request.user.get_profile().financial_institution
txn = Transaction.objects.extra(
where=['(tpin=%s or teller_no=%s or identifier=%s) AND
financial_institution_id=%s'],
    params=[value, str(value), value, fi.id])

-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: How can I use {{variable}} in custom templatetag?

2011-08-08 Thread Ian Clelland
On Mon, Aug 8, 2011 at 4:36 PM, Josh <jos.carpente...@yahoo.com> wrote:

> >
>>
>> >If you need to push back a value in a variable call related_entries, then
>>> you will want to set a value in the context dictionary:
>>
>> >
>>
>> >context[related_entries] = 
>>
>>
> Correction on earlier mail when trying some other things. I do this in the
> def render. This looks like:
>
> class RelatedEntryNode(template.Node):
>
> def __init__(self, model, number, categories, varname):
> self.model = model
> self.number = int(number)
> self.categories = template.Variable(categories)
> self.varname = varname
>

Ok, so this means that:
self.model is a string; literally, in your example, "weblog.entry"
self.number is an integer
self.categories is a variable reference -- you can resolve it at render
time, to obtain the value of object.categories (or, depending on what object
happens to be, Django could try object['categories'], or
object.categories(), or a few other things -- the important thing is that
the Django template framework will do the work of getting you a value)
self.varname is another string; in this case, "related_entries"

Now, I *think* that you want self.model to be a Variable as well, just like
self.categories, because I *don't think* that you are actually interested in
the string "weblog.entry" -- I think that you want the value of the entry
attribute of the weblog object. You want Django to resolve that value for
you at template render time.


>
> def render(self, context):
> related = self.categories.resolve(context)
> context[self.varname] = related
> return ''
>
>
> >
>>
>> >You won't be able to resolve it as a Variable, because it (presumably)
>>> doesn't even exist >before you call your custom tag, but once you set it on
>>> the context object, it will be >available to the rest of the template.
>>
>>
>>> This I don't understand. As I understand Django (but correct me if I'm
>>> wrong) the related_entries should be a dictionary or list  of
>>> Entry-instances.
>>
>>
>>
That depends entirely on what *you* want *your template tag* to do. Given
all of your descriptions, though, I'm led to believe that you want your tag
to create a new variable, which you can use in your template. So, when you
put

{% get_related_entries weblog.entry 5 from object.categories as
related_entries %}

in your template, {{related_entries}} doesn't exist as a variable *before*
your tag, but *after* your tag, it has some value, which you will have
computed in the render() method.

In that case, then *in your node class*, self.related_entries is just a
string -- the name of the variable to create. In your example, it happens to
be the string "related_entries", but you could have written

{% get_related_entries weblog.entry 5 from object.categories as
cheeseburger_hotel %}

and then self.related_entries would contain the string "cheeseburger_hotel".
But that's fine, because your render() method is going to compute some
value, probably a list of Entry instances in this case, and then it will
create a new context variable, with the statement;

context[self.related_entries] = 

And that is what is going to create the context variable
{{related_entries}}, or {{cheeseburger_hotel}}, or whatever the template
author asked for.


I hope that helps -- I think that you may be confusing things by using the
same names for your python variables as you do for your template variables,
when they really are very different things.



-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: How can I use {{variable}} in custom templatetag?

2011-08-08 Thread Ian Clelland
On Mon, Aug 8, 2011 at 2:20 PM, Josh <jos.carpente...@yahoo.com> wrote:

> >It sounds like you're not resolving the variable at all in your render
> method --
> >
> >When you construct the template node, you work with Variable objects,
> which represent the >context variable as it exists in the template source
> (eg, html).
> >
> >At the point where you actually render your output, you want to resolve
> that Variable, so >that the template framework actually determines what the
> contents of that variable should >be, given the current context.
> >
> >The example at
> https://docs.djangoproject.com/en/1.3/howto/custom-template-tags/#passing->template-variables-to-the-tag
> shows how it should be done. Construct a Variable object in
> >node.__init__(), and use variable.resolve(context) in node.render()
> >
> >Ian
>
> I already tried that route from the sample and that creates the unicode
> error. Relevant parts of my code are below.
>
>
These are my assumptions about the bits of code you've posted:


> models.py
> categories = models.ManyToManyField('Category', blank=True, null=True,
> default = None)
>

Assumption: categories is a field defined within a standard Django model;
Category is another model you have defined.


>
> {% get_related_entries weblog.entry 5 from object.categories as
> related_entries %}
>  {% for entry in related_entries %}
>   {{ entry.title }}
>  {% endfor %}
>
>
Assumption: weblog and object are context variables provided to the template
from the view. object is an instance of the model with the categories m2m
field you showed above.

I'm not sure how weblog.entry is relevant.



>
> def __init__(self, model, number, categories, varname):
> self.categories = template.Variable(categories)
>

Assumption: model, number, categories, and varname are the parameters from
the template tag you show in the template snippet above. I am guessing that
they are all just the strings, exactly as they appear in the template.

>
>
> def render(self, context):
> related = self.varname.resolve(context)
> return related
>

At this point, I presume that you have defined self.varname in __init__
above, as "self.varname = varname", and you have just chosen not to paste
that line.


>
> *Caught AttributeError while rendering: 'unicode' object has no attribute
> 'resolve'*
>

First off, self.varname, if I am correct, is just the string
"related_entries" here. It doesn't have a "resolve" method, because it's
just a string. Variable objects, like self.context, have a "resolve"
method.

If you want to access the categories that you have mentioned in the
template, then you can use
self.categories.resolve(context)

If you want to access "weblog.entry", then you will need to create a
Variable from it, like you did with categories:

def __init__(...):
...
self.model = template.Variable(model)
...

and then resolve it in render(), as self.model.resolve(context)

If you need to push back a value in a variable call related_entries, then
you will want to set a value in the context dictionary:

context[related_entries] = 

You won't be able to resolve it as a Variable, because it (presumably)
doesn't even exist before you call your custom tag, but once you set it on
the context object, it will be available to the rest of the template.

Hope this helps,

Ian




*
> *
> When I view the entry.categories from the manage shell, it returns a list
> of categories (I also tried with from object instead of object.categories in
> the templatetag, but that gave the same error)
>
> In [7]: c.categories.all()
> Out[7]: [, , ]
>
> Somehow I have to iterate the list of categories (which consist of the name
> and not the Category.id and retrieve other entries with the same category in
> the Node render. I have been looking into include-tags too, but I also got
> iterating errors. I cannot imagine that there isn't an easy solution for
> these kind of queries. These kind of queries are pretty common to perform,
> but how ???
>
>  --
> 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/-/KsGYSEO2NUkJ.
>
> 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.
>



-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: How can I use {{variable}} in custom templatetag?

2011-08-08 Thread Ian Clelland
On Mon, Aug 8, 2011 at 12:14 PM, Josh <jos.carpente...@yahoo.com> wrote:

> >{% get_related_entries weblog.entry 5 from object.categories as
> related_entries %}
>
> I found that out already. Now I'm pretty sure the problem is in the
> rendering. As far as I can tell ( I don't know how to test template tags in
> a shell ) I get a list of the names of the categories back.
>
>
>- When I try to iterate the list, I get the  'Caught TypeError while
>rendering: 'Variable' object is not iterable' error.
>- When I don't iterate the variable I get the 'Caught TypeError while
>rendering: int() argument must be a string or a number, not 'Variable'
>- When I try to append queries (with Q or the normal way, because I
>need an OR relation), that works neither.
>
> It sounds like you're not resolving the variable at all in your render
method --

When you construct the template node, you work with Variable objects, which
represent the context variable as it exists in the template source (eg,
html).

At the point where you actually render your output, you want to resolve that
Variable, so that the template framework actually determines what the
contents of that variable should be, given the current context.

The example at
https://docs.djangoproject.com/en/1.3/howto/custom-template-tags/#passing-template-variables-to-the-tag
shows
how it should be done. Construct a Variable object in node.__init__(), and
use variable.resolve(context) in node.render()

Ian


>
>-
>
> ??? I don't know how to continue. I'm thinking now of solving this outside
> Django in a 'normal' python script (somehow) and pass the values as
> formatted html back to the template. That shouldn't be necessary I think.
> I'm sure I'm overlooking a very fundamental issue with templates and
> templatetags, but I just don't get it (yet).
>
> --
> 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/-/yYKP0Xoz9XkJ.
>
> 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.
>



-- 
Regards,
Ian Clelland
<clell...@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: object value distinct for ForeignKey

2011-07-27 Thread Ian Clelland
On Wed, Jul 27, 2011 at 9:29 AM, Ian Clelland <clell...@gmail.com> wrote:

>
>
> On Mon, Jul 25, 2011 at 11:29 AM, Alfredo Alessandrini <
> alfreal...@gmail.com> wrote:
>
>> Hi,
>>
>> I've a model testDB with a foreignkey "country" related to another
>> database.
>>
>> I need to retrieve the unique value of country.common_name.
>>
>> With this
>>
>> country_list = testDB.objects.values('country').distinct
>>
>> I can retrieve the unique value, but only the ID.
>>
>> In [63]: testDB.objects.values('country').distinct
>> Out[63]: > {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
>> {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
>> {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
>> {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
>> {'country': 0L}, {'country': 0L}, {'country': 0L}, '...(remaining
>> elements truncated)...']>
>>
>> How can I  retrieve the attribute "common_name" of the country object?
>>
>
> The "" is usually a clue that what you have retrieved is
> actually a method, and you haven't called that method yet.
>
> Try:
> testDB.objects.values('country').distinct()
>
> (Although you should probably also read the note here:
> https://docs.djangoproject.com/en/1.3/ref/models/querysets/#distinct to
> see why you might want to  be writing
> testDB.objects.order_by().values('country').distinct() )
>
>

And this time, I'll actually respond after reading the last line of your
question -- if what you want is a list of distinct country *names*, where
the name is a field on the country object, you are looking for somethng like
this:

testDB.objects.order_by().values('country__common_name').distinct()


-- 
Regards,
Ian Clelland
<clell...@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: object value distinct for ForeignKey

2011-07-27 Thread Ian Clelland
On Mon, Jul 25, 2011 at 11:29 AM, Alfredo Alessandrini <alfreal...@gmail.com
> wrote:

> Hi,
>
> I've a model testDB with a foreignkey "country" related to another
> database.
>
> I need to retrieve the unique value of country.common_name.
>
> With this
>
> country_list = testDB.objects.values('country').distinct
>
> I can retrieve the unique value, but only the ID.
>
> In [63]: testDB.objects.values('country').distinct
> Out[63]:  {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
> {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
> {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
> {'country': 0L}, {'country': 0L}, {'country': 0L}, {'country': 0L},
> {'country': 0L}, {'country': 0L}, {'country': 0L}, '...(remaining
> elements truncated)...']>
>
> How can I  retrieve the attribute "common_name" of the country object?
>

The "" is usually a clue that what you have retrieved is
actually a method, and you haven't called that method yet.

Try:
testDB.objects.values('country').distinct()

(Although you should probably also read the note here:
https://docs.djangoproject.com/en/1.3/ref/models/querysets/#distinct to see
why you might want to  be writing
testDB.objects.order_by().values('country').distinct() )


>
> thanks in advance,
>
> Alfredo
>
> --
> 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.
>
>


-- 
Regards,
Ian Clelland
<clell...@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: in my model, how can I tell when I'm saving a new item

2011-07-25 Thread Ian Clelland
On Mon, Jul 25, 2011 at 4:05 PM, webcomm <rya...@gmail.com> wrote:

> > Thanks.  Any idea why the following isn't working in my News class?
> > The processing doesn't get to that exit call, even if it's a new item.
> >
> > def save(self, *args, **kwargs):
> > if not hasattr(self,'id'):
> > import sys
> > sys.exit('must be a new item')
> > super(News, self).save(*args, **kwargs)
>
>
> hasattr doesn't work in this situation, or I'm not using it right.  In
> any case, the following works:
>
>def save(self, *args, **kwargs):
> if not self.id:
>import sys
>sys.exit('a new item')
> super(News, self).save(*args, **kwargs)
>

webcomm,

Whether you have defined an 'id' field in your model, or let Django do it
for you, each of your objects will "have" an id attribute, and so
hasattr(my_object, 'id') will always be true. The *value* of that attribute
might be None, though, and that's why works when you simply test self.id,
like you did above.

hasattr is generally useful in a function when you are not sure what kind of
object has been passed in, or if you want to tell whether an object has been
augmented with a specific attribute. When you know that the attribute
exists, then you can use getattr(self, "id"), or just access the attribute
directly (like "self.id")


That being said, though, there are situations where you can't rely on an id
being a guarantee that the object already exists. Like any field, it is
possible to specify the id when creating an object in memory, like this:

new_object = News(id=1, headline="Breaking news!", content="Database
broken!")
new_object.save()

This object will have an id set when the save() method checks for it, and so
any code that you needed to run for new items will be skipped.

In fact, this is exactly what happens when you load fixtures, either with
"manage.py loaddata", or by using fixtures in tests.

If there is code that absolutely has to run when a new object is created,
(or code that needs to run on update, but absolutely cannot run on new
objects before insertion), then you may be better off using a post-save
signal handler, and checking the "created" argument that gets passed to it.


-- 
Regards,
Ian Clelland
<clell...@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: 'settings' referenced before assignment

2011-07-20 Thread Ian Clelland
On Wed, Jul 20, 2011 at 1:14 PM, ydjango <traderash...@gmail.com> wrote:

> Occasionally I see this error in my app,
>
> UnboundLocalError: local variable 'settings' referenced before
> assignment
>
> I have in my views .py
>
> from django.conf import settings
> other imports...
>
> def new_view(request):
>if not request.user.is_authenticated():
>return HttpResponseRedirect(settings.ENV_URL) <-=== this
> is where error is thrown.
>...
>
> What could be the reason? How can I prevent from occurring.
>
> I am using django 1.1, python 2.5 and mod_wsgi
>
>
If, later in your view function, you have an assignment to settings,
something like

settings = "abcde"

then, when the Python parser first examines your function, it will classify
settings as a local variable, regardless of whether it is imported above or
not. Accessing that local variable before its first assignment will be
considered an error, and Python will refuse to compile the function.

To fix this, you should either put "global settings" at the top of your
function (if you really do want to overwrite it), or remove the assignment
to the 'settings' variable (if you don't), or change the name of the
variable you assign to (if it was an accident).


-- 
Regards,
Ian Clelland
<clell...@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: Calling a custom templatetag inside a block/extrahead-block?

2011-07-04 Thread Ian Clelland
On Monday, July 4, 2011, Thomas Weholt <thomas.weh...@gmail.com> wrote:
> I've created a templatetag called {% kolibri_imports %} which I use
> the in the head-section of my templates. It imports related to
> stylesheets, javascript libraries etc for my kolibri-package. This
> works fine when I've control over the base-template I'm extending, but
> when I want to extend a template which defines a extrahead for me to
> add stuff to, I get an error trying to call my
> kolibri_imports-templatetag. Now I want to call that templatetag
> inside a
>
> {% block extrahead %}
> {% kolibri_imports %}
> {% endblock %}
>
> but I get the following error:
>
> Invalid block tag: 'kolibri_imports', expected 'endblock' or 'endblock
> extrahead'
>
> So; How can I call a defined templatetag inside my {% block extrahead
> %}-block? I've tried
>
> {% block extrahead %}
> {{kolibri_imports }}
>
> But that didn't produce anything.
>
> This is probably simple, but ... thanks for you input.
>
> --
> Mvh/Best regards,
> Thomas Weholt
> http://www.weholt.org
>
> --
> 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.
>
>

Are you loading the template tag library in the template that extends the base?

-- 
Regards,
Ian Clelland
<clell...@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: Calling a custom templatetag inside a block/extrahead-block?

2011-07-04 Thread Ian Clelland
On Monday, July 4, 2011, Thomas Weholt <thomas.weh...@gmail.com> wrote:
> I've created a templatetag called {% kolibri_imports %} which I use
> the in the head-section of my templates. It imports related to
> stylesheets, javascript libraries etc for my kolibri-package. This
> works fine when I've control over the base-template I'm extending, but
> when I want to extend a template which defines a extrahead for me to
> add stuff to, I get an error trying to call my
> kolibri_imports-templatetag. Now I want to call that templatetag
> inside a
>
> {% block extrahead %}
> {% kolibri_imports %}
> {% endblock %}
>
> but I get the following error:
>
> Invalid block tag: 'kolibri_imports', expected 'endblock' or 'endblock
> extrahead'
>
> So; How can I call a defined templatetag inside my {% block extrahead
> %}-block? I've tried
>
> {% block extrahead %}
> {{kolibri_imports }}
>
> But that didn't produce anything.
>
> This is probably simple, but ... thanks for you input.
>
> --
> Mvh/Best regards,
> Thomas Weholt
> http://www.weholt.org
>
> --
> 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.
>
>

Are you loading the tem

-- 
Regards,
Ian Clelland
<clell...@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: Strip_tags and non english char issue

2011-06-26 Thread Ian Clelland
On Fri, Jun 24, 2011 at 5:21 PM, ydjango <neerash...@gmail.com> wrote:

> Just checking if anyone has any pointers?
> We are using Django 1.1.4
>
> On Jun 15, 2:03 pm, ydjango <neerash...@gmail.com> wrote:
> > I have rich text (in utf8) which I want to show in standard browser
> > tooltip.
> >
> > I strip html tags using strip_tags as they show as html tags in
> > tooltip.
> >
> > Issue is that it seems strip_tags is stripping or converting certain
> > turkish characters like ü   into weird special chars?
> >
> > I am unable to use django template's safe tag as data goes from django
> > view to xml to javascript.
> >
> > We are using UTF8 encoding in DB.
> >
> > Any ideas on how to solve?
>
>
It's very hard to say what might be going on here -- the strip_tags filter
is very simple, and is mostly just a regular expression applied to your
input. A large number of other people, I am sure, are using the tag without
noticing any such problem.

The one spot in the code that I can see that might cause problems is
django.utils.encoding.force_unicode -- it's possible that you are passing
something unexpected to that, and it is performing a conversion which
produces the characters you are seeing.

If you want to troubleshoot this, I would suggest the following:

1. Can you confirm that the data is really in the database in UTF8?

2. What do you get when you query the database from Django? At a minimum, I
would run a Django shell, import the models, and get a problematic instance
out of the database for printing. If you print the fields ("print
repr(my_instance.field_name)"), you should be able to see a proper unicode
object, something like u"This is the text with the ü")

>>> from my_app.models import MyModel
>>> my_instance = MyModel.objects.get(id=1234)
>>> print repr(my_instance.field_name)

3. What happens when you pass that string to force_unicode?

>>> from django.utils.encoding import force_unicode
>>> print repr(force_unicode(my_instance.field_name))

4. What are you actually getting as HTML output? Django should be outputting
unicode, so you will have to ensure that your web server is providing an
appropriate Content-Type header, or that you have a  tag in the html
header that specifies unicode. If those aren't there, then your browser will
have to guess the document encoding, and might be guessing wrong.

Hopefully that should get you enough visibility on the problem to see what
is happening. If none of that provides any clarity, then try posting those
answers here, and someone might be able to tell what's going on.

-- 
Regards,
Ian Clelland
<clell...@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: Inconsistent keyword filtering on FK

2011-06-23 Thread Ian Clelland
On Thu, Jun 23, 2011 at 2:21 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> The problem:
>>
>> Utility.objects.filter(person=1144) # works fine
>> Payee.objects.filter(person=26) # gives us FieldError: Cannot resolve
>> keyword 'person' into field
>>
>
> Is this what you need??
>
> Payee.objects.filter(
> person = Person(id=26)
> )
>
> or.. Payee.objects.filter(
> person__id = 26
> ) - but this would be slightly more performance hitting i think.
>

or just

Payee.objects.filter(person_id=26)

person__id is a field lookup on the person model, so (in theory) Django will
contruct the SQL join, and test the person.id column. person_id is a column
in the payee table, and Django will construct SQL which compares against
that.

I don't know if there's any practical difference in performance -- I would
hope that any decent SQL query optimizer should be able to change

select payee.* from payee join person on (payee.person_id = person.id) where
person.id = 26

into

select payee.* from payee where person_id = 26


-- 
Regards,
Ian Clelland
<clell...@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: Unit-Testing Dilemma

2011-06-21 Thread Ian Clelland
On Tue, Jun 21, 2011 at 7:30 AM, Nan <ringe...@gmail.com> wrote:

>
>
> > Your view function may indeed be too complex to test properly, and it
> sounds
> > like it is too tightly coupled with with the API call -- there is no way
> to
> > call the view without having it call the actual 3rd-party API as imported
> at
> > the top of the file.
>
> I'd be a little confused as to how to factor that out.  I mean, in the
> actual app that call is refactored behind a function that wraps the
> third-party API, and I could theoretically monkey-patch something over
> that function call for unit testing.  But the view still has to return
> an HttpResponse, and a blank one.
>

You're right, the view does need to return an HttpResponse; there's nothing
you can do about that. My point about tight coupling was that your view has
also been made responsible for instantiating the API wrapper that it thinks
it needs, and there's no way to tell it not to. In other frameworks, I would
immediately suggest using dependency injection -- the view depends on an API
wrapper instance, so it shouldn't be creating that instance; that should be
provided to it:

def my_view(request, api):
...
result = api.call(msg)

because then you could call my_view(request, theAPI()) in most
circumstances, but my_view(request, fake_api) in test code. Unfortunately,
the view is almost always called directly by Django, and you don't have much
control over its parameters.


> > The other way is to make your view function as simple as possible --
> simple
> > enough that it is obviously correct, without any unit tests. Take
> > *everything* that can affect the message which is passed to the API, and
> > abstract that into another function that the view can call. Then test
> *that*
> > function as a unit.
>
> Yes, it is very complex: it has to assess about 30 different potential
> states via nested conditionals.  It's actually broken down into a
> number of sub-functions that each deal with a few sub-states; and
> while refactoring might be a good idea, I wouldn't want to even
> attempt that before having some good unit tests in place!
>
> I think what you're suggesting (correct me if I'm wrong) is to have
> the top-level view function be the only place the API is called, and
> to use only a single call; every other sub-function that reaches an
> exit state should instead return a string containing the message to
> send?
>

That's what I was suggesting; that way the view becomes simple enough that
anyone looking at it can be assured of its correctness, without a host of
unit tests. Those tests can be applied to the functions that actually
construct the messages. But, see below -- I didn't realise that this effort
was to aid in refactoring the code.


>
> Thinking aloud, my concern then becomes that some of the sub-functions
> must actually make multiple API calls.  So we'd have to be returning
> tuples or something instead.
>
> > If theAPI is a class, then give it methods like setTestMode() and
> > resetTestMode(), and use them in your setUp and tearDown methods. Then,
> if
> > test mode is enabled, don't actually make the third party call, just
> store
> > the passed-in message in a module-level or class-level list and return
> > success. After your view returns, check the list to see that the message
> was
> > correct.
>
> Oh!  Thank you!  I didn't understand before how a mock API might make
> that possible -- it makes a lot more sense now.  That soudns like the
> perfect way to do it.
>
> At least until we've got enough tests to make sure the refactoring is
> correct, I need to be able to create the tests without touching the
> actual view logic, so testing what the API receives makes the most
> sense to me.
>

If this is all for a refactoring, then you're probably on the right track
there -- instrument the existing object for testing, rather than
restructuring the view first. Get the code into a state where you can trust
it, and then you can start restructuring it to make it more easily testable
in the future.

Good luck! :)


-- 
Regards,
Ian Clelland
<clell...@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: Possible bug in form validation

2011-06-20 Thread Ian Clelland
On Mon, Jun 20, 2011 at 1:49 PM, Shawn Milochik <sh...@milochik.com> wrote:

> I know that, whenever someone finds a "bug" in Django they're usually doing
> something incorrectly. Hopefully someone will point out what I need to do to
> make this work.
>

I don't know if it's considered 'correct' or not, but the max_value
constructor parameter is only used at instantiation time, to add a validator
to the field.

You can easily add the validator manually in your own constructor if you
need to. You may also want to set the max_value attribute, if you use it
elsewhere, but it is not used internally by the form machinery.


>
> However, this is looking like a legitimate bug to me.
>
> http://dpaste.com/hold/556603/
>
>
I've updated with a working example, as http://dpaste.com/hold/556805/

-- 
Regards,
Ian Clelland
<clell...@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: Unit-Testing Dilemma

2011-06-20 Thread Ian Clelland
On Mon, Jun 20, 2011 at 4:25 PM, Nan <ringe...@gmail.com> wrote:

>
> Hm, I'm not worried about receiving a valid response from the third-
> party API, just about testing the value of the "msg" parameter that's
> passed into it.  I need to test the msg parameter because it is in
> turn essentially a proxy for which state was reached in my_view.
>
> my_view is actually a great deal more complex than in the example, and
> is indeed broken into many smaller function calls.  I need to unit
> test to make sure that the logic is correct -- and since all those
> function calls return empty HttpResponse objects, I can't use their
> return values to test the correctness of their logic.
>

Your view function may indeed be too complex to test properly, and it sounds
like it is too tightly coupled with with the API call -- there is no way to
call the view without having it call the actual 3rd-party API as imported at
the top of the file.

There are a couple of ways out of this -- one is to use mocks, as suggested
before. Coupled with the dependency injection pattern, you would normally do
something to have the testing framework pass the mock API to the view, and
then you would query the mock at the end of the test to see what was passed
to it. Since Django's test framework is based around end-to-end testing
(making requests through TestCase.client and examining the response
returned,) this can be difficult to achieve.

The other way is to make your view function as simple as possible -- simple
enough that it is obviously correct, without any unit tests. Take
*everything* that can affect the message which is passed to the API, and
abstract that into another function that the view can call. Then test *that*
function as a unit.


>
> Just brainstorming here, could there be a way around this by placing a
> logging call of some sort in theAPI.call() that would only be executed
> during unit testing, and then to test the contents of the log?
>

This sounds like turning your API wrapper into a mock object at test time --
it might be the easiest way to do it, if you go the mock route.

If theAPI is a class, then give it methods like setTestMode() and
resetTestMode(), and use them in your setUp and tearDown methods. Then, if
test mode is enabled, don't actually make the third party call, just store
the passed-in message in a module-level or class-level list and return
success. After your view returns, check the list to see that the message was
correct.

Depending on the tests you have, you may want to have a way to tell the API
to return success or various kinds of failure. Most mocking frameworks have
ways of telling the mock objects what to return before making the method
calls.

At some point, though, I would start to become wary of putting too much
testing code in the real classes. (I'm sure there's an unpleasant name for
that kind of pattern)


>
>
> On Jun 20, 6:20 pm, DrBloodmoney <drbloodmo...@gmail.com> wrote:
> > On Mon, Jun 20, 2011 at 3:52 PM, Nan <ringe...@gmail.com> wrote:
> > > I'm not testing the third-party service.  I need to test *what I send
> > > to them*.  I.e. that the output of my_view is correct.  The trouble is
> > > that neither my_view nor the API call actually returns the output that
> > > I need to check.
> >
> > > Does that make sense?
> >
> > Mock is one good solution. Here's what I've done in the past
> > (basically half-assed mock):
> >
> > 1. Have representative data sets that are good for the service (eg.
> > whatever you send to them, and whatever they send you in return).
> > 2. Monkey patch the call:
> >
> > def hackety_patch():
> > from StringIO import StringIO
> > data = StringIO(testdata_response_from_API)
> > data.seek(0)
> > return data.read()
> >
> > # in TestCase subclass
> > def setUp(self):
> > third_party.api.urllib2.urlopen = hackety_patch
> >
> > def tearDown(self):
> > third_party.api.urllib2.urlopen = urllib2.urlopen
> >
> > 3. Break up your API calling code into more testable units to truly
> > isolate your independent code from the API calling code. It'll be much
> > easier to catch problems in the API integration code.
>
> --
> 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.
>
>


-- 
Regards,
Ian Clelland
<clell...@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: storing django object into javascript variable/array

2011-06-15 Thread Ian Clelland
On Wed, Jun 15, 2011 at 7:27 AM, jay K. <jay.developer2...@gmail.com> wrote:

> Hello,
>
> I've posted my question before, but I believe I didn't provide enough
> detail. I intend to present my issue again, this time with more
> detail.
>
> Let me tell you that I am not a django developer, so I have very
> limited exposure to django. I just know html, css, javascript, jquery,
> php (also java and c++, so I'm familiar with object-oriented
> programming).


...


>
> Now, I manage to see the output of the javascript written above
> through Firefox's "View - Page Source" and it comes up like this
>
> //BEGINNING
> var city_schools = ["EC","St. Giles Central","St. Giles Highgate"];
>
> var city_latitudes = ["58","88","25"];
>
> var city_longtitudes = ["7","99","100"];
>
> //END
>
>
> I have a separate javascript file where I add the code for the google
> map. What I want to do is to be able to access each of the
> city_schools, city_latitudes, and city_longitudes and use its data to
> I can mark the schools inside a google map. It would be ideal if I
> could retrieve the info as if it was a js array, but any method that
> works is more than welcome
>

What you have is very clearly a JavaScript array, as you asked for the first
time you posed this question. In fact, by copying the code, you have
produced three JavaScript arrays.

What you haven't done, in this newest version of your question, is show
exactly what it is you want. We now have a rough idea of what your models
look like, but no idea at all why the JavaScript output you have pasted is
insufficient.

You say that you know JavaScript, so what you're going to have to do is come
up with a sample of what you'd *like* to see as the template output, and
hopefully we can help you with the Django template code to produce that
output.

[Also, it really doesn't help to be posting and reposting the same question,
just hours apart -- it just looks very impatient]

-- 
Regards,
Ian Clelland
<clell...@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: Could not decode to UTF-8 column 'cpostal'

2011-06-13 Thread Ian Clelland
On Sun, Jun 12, 2011 at 11:27 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> I could be wrong, but I'm fairly sure that \xc3\xa3 is a 4 byte unicode
> sequence (which is essentially UTF-16).


No, it's a two-byte sequence -- the UTF-8 encoding of code point
U+00E3, 'LATIN SMALL LETTER A WITH TILDE'.

The original mysql data is probably the latin-1 byte string
'...Famalic\xe3o...'; str.decode('iso-8859-1') converts that into a unicode
string with the U+00E3 code point, and then unicode.encode('utf-8') is
representing that as \xc3\ca3. All correct, up to this point.

It looks like, after this decoding has occurred, and everything is stored,
either the sqlite adapter is returning the wrong data type when retrieving
data from the database, or admin is presenting something unexpected back to
sqlite when saving.

A couple of questions to the original poster might clarify a bit --

1. When do you get this error in admin? When looking at an object list page?
Or looking at an object detail page? Or only when saving objects?

2. Was your custom text_factory used only when you were porting the data
from mysql to sqlite? Or is it still present in your running application?
(And if so, where do you register it?)

3. Are you sure that the data is being stored and retrieved from the
database correctly? What output do you get from the python shell to confirm
that? (It's easy to retrieve wrong data that looks "right enough" when
printed to a terminal). If I was pulling correct data from the database, I
would expect to see something like this:

> from myapp.models import MyModel
> object_from_database = MyModel.objects.get(id=123)
> object_from_database.field_name   # not using "print" here
u'4760 Vila Nova de Famalic\xe3o'

Anything else -- missing the "u", or showing \xc3\xa3 instead of \xe3 here,
would suggest that something is wrong in the database (either stored
incorrectly, or being mis-translated somewhere on retrieval)

4. If you can get the right data out of the database in the python shell,
then can you save it from there as well? If everything above works, then try
doing this:

> object_from_database.save()

and see if you get the same error. If so, posting a traceback from that
might help pinpoint the problem.



-- 
Regards,
Ian Clelland
<clell...@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: forms messing up css, help?

2011-06-11 Thread Ian Clelland
I have no idea what you mean by "stop working" -- without knowing what the
code looked like before, I don't know how it worked before. The usual rule
is that if something worked before, and doesn't work now, then the problem
is in something that you did in between.

Now if this is a new view, and has never worked at all, then that's
different.

At a first glance, you are using "render_to_response" in your view. This
method creates a Context object out of the dictionary that you pass it (in
your case, {'form': form} ).

A Context object doesn't know anything about the request, so {{ request.path
}} won't work in the template. It also doesn't have any ContextProcessors
applied, so you won't have access to context variables like {{ STATIC_URL
}}. The *only* variable that will be available in your template is {{ form
}}, because you passed it in.

What you want is a RequestContext object, rather than a Context object. You
can get one in your template, by adding one parameter to render_to_response:

from django.template import RequestContext
...
def contact(request):
...
render_to_reponse(
'/var/djcode/oneadmin/templates/oneadmissions/contact.html',
{'form': form},
context_instance=RequestContext(request)
)

That should give you a functioning template.

Ian

On Fri, Jun 10, 2011 at 9:27 PM, raj <nano.ri...@gmail.com> wrote:

> I also noticed one more thing, in general, all html functions stopped
> working with render_to_response i think. Like i have a function that
> gets the current path ({% request.path == ".." %}). That also isn't
> working. And even when I hard-code it, it doesn't make a difference.
> any suggestions?
>
> On Jun 11, 12:17 am, raj <nano.ri...@gmail.com> wrote:
> > Another thing i just noticed, When i view the source of my contact
> > form, all the css/javascript includes are missing part of the path
> > where i placed a {{ STATIC_URL }} tag. Why isn't this tag being
> > rendered? Thank you.
> >
> > On Jun 11, 12:14 am, raj <nano.ri...@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Hey guys, Whenever i try and add a contact form (from the django book)
> > > into my current website, all my css/javascripts stop working. What is
> > > the issue? Here are my codes:
> >
> > > #views.py
> >
> > > def contact(request):
> > > if request.method == 'POST':
> > > form = ContactForm(request.POST)
> > > if form.is_valid():
> > > cd = form.cleaned_data
> > > send_mail(
> > > cd['subject'],
> > > cd['message'],
> > > cd.get('email', 'nore...@example.com'),
> > > ['siteow...@example.com'],
> > > )
> > > return HttpResponseRedirect('/contact/thanks/')
> > > else:
> > > form = ContactForm()
> > > return render_to_response('/var/djcode/oneadmin/templates/
> > > oneadmissions/contact.html', {'form': form})
> >
> > > #forms.py
> >
> > > from django import forms
> >
> > > class ContactForm(forms.Form):
> > > subject = forms.CharField()
> > > email = forms.EmailField()
> > > message = forms.CharField()
> > > name = forms.CharField()
> >
> > > #urls.py
> > > urlpatterns = patterns('',
> > > ...
> > >  (r'^contact-form/', views.contact),
> > > ...
> > >  )
> >
> > > I have my static folder and everything created properly, its working
> > > perfectly fine until i input the chapter on forms. Help please!
>
> --
> 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.
>
>


-- 
Regards,
Ian Clelland
<clell...@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: storing django object into javascript array

2011-06-10 Thread Ian Clelland
On Fri, Jun 10, 2011 at 7:48 AM, jay K. <jay.developer2...@gmail.com> wrote:

>
> Hello,
>
> I am not a django developer, but I have a background on html, css,
> javascript, jquery and php.
>
> I was wondering if you can help me with a question regarding django,
> since I'm working on a website built on django (which was not started
> by me)
>
> I want to store a django object into a javascript array. So far I have
> this code:
>
> In my template file:
>
> 
>
> var map_schools = {{ city.school_set.all }};
>
> 
>
> Unfortunately the django object is not stored as desired, but instead
> it gets stored like the following:
>
> var map_schools = [School: Oxford, Eckersley]
>
>
[] is the printable representation of your query
set (what you get when you call city.school_set.all()) -- what you need to
do is build up a JavaScript literal that you can insert into the code. There
are two fairly simple ways of doing this:

1. Use a loop in the template:

var map_schools = [{% for school in city.school_set.all %}"{{
school|escapejs }}"{% if not forloop.last %},{% endif %}{% endfor %}];

You'll notice a couple of things there:
  - there is a "for" loop there, to iterate over all of the schools in the
result set
  - the quotes are present in the template, to make sure that the school
names are strings in the JavaScript
  - there is a test after every string to see if a "," is needed as a
separator (some javascript implementations are not very forgiving if you put
a comma after the last element)
  - Every school name is passed through the "escapejs" filter, to avoid
breaking out of the string.

2. Construct a JSON string in python:

In your view, do something like this:

from django.utils.simplejson import dumps
...
school_list = dumps([school.name for school in city.school_set.all()])

and then add school_list to the context variables that are passed to the
template. Then in the template, you can just use {{ school_list }}, and it
will be a properly formatted JavaScript array.



-- 
Regards,
Ian Clelland
<clell...@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: 'ValuesListQuerySet' object has no attribute 'META'

2011-06-10 Thread Ian Clelland
On Fri, Jun 10, 2011 at 5:55 AM, javatina <serge.i...@gmail.com> wrote:

>
> = in views.py: ===
> see formatted http://dpaste.com/hold/552703/
>
> same as:
>
> def test(request, slug=None):
>slugs = Concept.objects.filter(status__slug = 'active').order_by('-
> published_on').values_list('slug', flat=True)
>try:
>concept = Concept.objects.get(slug = slug, status__slug =
> 'active')
>except Page.DoesNotExist:
>raise Http404
>
>slugs_list = list(slugs)  # ==> problem line
>
>
>

> =  traceback =
> http://dpaste.com/552702/
>

 According to your traceback, when you call list(slugs), on line 446, it is
not using the python list() built-in, but calling what appears to be a list
function that you have defined earlier (around line 400)

My initial guess would be that you have something like this above the code
you have pasted:

def list(request):
...
context_instance=RequestContext(request)
...

And that call is throwing an exception, because you are passing a QuerySet
into RequestContext(), which is expecting an HttpRequest, and its
accompanying META attribute.

Check to see if that's the case, and rename your list() view if it is.

-- 
Regards,
Ian Clelland
<clell...@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: 'ValuesListQuerySet' object has no attribute 'META'

2011-06-09 Thread Ian Clelland
On Thu, Jun 9, 2011 at 11:00 AM, javatina <serge.i...@gmail.com> wrote:

> I need a list of all IDs for model records. So, I do this
> concept_ids = Concept.objects.values_list('concept_id', flat=True)
>
> concept_ids is a ValuesListQuerySet - I got it. According to docs
> since ValuesListQuerySet is a subclass of QuerySet I can do
> list(concept_ids) - see
>
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#when-querysets-are-evaluated
>
> However, I am getting on this line
> 'ValuesListQuerySet' object has no attribute 'META' error.
>
> For the sake of experimentation, if I try
> concept_ids = list(Concept.objects.all())
>
> I am getting 'QuerySet' object has no attribute 'META'. But this is
> like in docs (see link above):
> entry_list = list(Entry.objects.all())
>
> What am I doing wrong?
>


What are you doing with the list once you generate it? Are you just running
that single line of code, for instance, in a Python shell, or is this error
generated in a view?

"META", in all caps like that, is only used in Django as an attribute of an
HttpRequest object. The string "META" doesn't even occur in the db package,
so I can't imagine how simply wrapping a QuerySet in a list() call could
trigger an exception like that.

Can you post the rest of the code around this, or at least more of a
traceback, unless that is really all that there is? And if it is, then I'd
really like to take a look at your model definition.

-- 
Regards,
Ian Clelland
<clell...@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: Trouble with simple aggregation

2011-06-08 Thread Ian Clelland
On Wed, Jun 8, 2011 at 10:11 AM, Thomas Weholt <thomas.weh...@gmail.com>wrote:

> Say I got a model like so:
>
> class Article(models.Model):
>title = models.CharField(max_length=100)
>text = models.TextField()
>category = models.CharField(max_length=20)
>author = models.CharField(max_length=50)
>
> Article.objects.create(title="Foo", text="Story about foo",
> category="adventure", author="jane")
> Article.objects.create(title="Bar", text="Story about bar",
> category="adventure", author="joe")
> Article.objects.create(title="Cheese", text="Story about cheese",
> category="adventure", author="joe")
> Article.objects.create(title="Perl", text="Story about perl",
> category="horror", author="jane")
> Article.objects.create(title="Java", text="Story about java",
> category="horror", author="joe")
> Article.objects.create(title="Pizza", text="Story about pizza",
> category="cooking", author="joe")
>
> I've tried to use aggregation to find how many articles written by joe
> there are of each category, but so far I'm not getting anywhere.
>
> Desired output:
>
> [
>{'category': 'adventure', 'count': 2},
>{'category': 'horror', 'count': 1},
>{'category': 'cooking', 'count': 1}
> ]
>
> I just cant get my head wrapped around the orm aggregation, in this is
> easy using raw SQL, but I don't want to.
>

Is this not something like:

Article.objects.values('category').annotate(count=models.Count('id'))

? The idea being that you group the objects by category, and then count the
number of distinct ids within each category.

The docs mention that the default ordering can get in the way of this
sometimes, so you probably want to clear it first, like this:

Article.objects.values('category').annotate(count=models.Count('id')).order_by()

That should get you all of the data for your desired output -- it might not
be an actual list of actual dicts, but it should be structured in the same
way.

-- 
Regards,
Ian Clelland
<clell...@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: SystemError from django.conf.settings

2011-05-30 Thread Ian Clelland
On Sat, May 28, 2011 at 10:50 PM, Cameron <came...@sandboxsoftware.net>wrote:

> So I have this stack trace on my production server. I can't reproduce
> it locally and it doesn't occur with an older version of the same site
> deployed on the same server.
>
> Traceback (most recent call last):
>  File "./dependencies/django/core/handlers/wsgi.py", line 222, in
> __call__
>from django.conf import settings
> SystemError: ../Objects/tupleobject.c:118: bad argument to internal
> function
>


> 1. Anyone seen this before? The only other reference that I can find
> to that line of python is here (http://bugs.debian.org/cgi-bin/
> bugreport.cgi?bug=581626)
>

I've never seen this before. Looking at the Python source (you mentioned
that you're running 2.5.2 from Debian lenny,) this looks to me like it has
to be an error in a C module somewhere -- probably a third-party module, but
it's possible it's in the Python core somewhere.

The line itself is a sanity check in PyTuple_SetItem, which shouldn't even
be available to Python code (tuples are supposed to be immutable, right?) It
would only get triggered if it got called somehow with an argument that
wasn't actually a tuple, or with a tuple for which another reference existed
somewhere (besides in the initializing code).


>
> 2. Any tips on how I can find out what has changed to cause it? Aside
> from rolling back through weeks of revisions to find what triggered
> it.
>

If it's happening on settings import, then try importing settings manually
from a python shell. You may see more of a stacktrace that way. If you still
get the error, but can't pinpoint the failing line, then try running it
through the debugger, and step from line to line until you see it. If you're
lucky, there will be call to a function in an external module that triggers
it, and you'll be able to narrow the possibilities down to that one module.

Failing that, a binary search through weeks or even months of revisions
should only take O(lg n) time -- a small consolation, but searching weeks of
development is only a couple of iterations more than searching a few days.


> 3. I am about to try upgrading python to a newer version, is that
> likely to make any difference? I have already tried 2 different
> versions of uwsgi (0.9.6.8 and 0.9.7.2), but I don't want to mess
> around with the production environment too much, or risk breaking the
> live sites.
>

If the error is in one of the python core modules, then it may have been
fixed recently; but I haven't seen any reports of failures in tupleobject.c
other than the Trac bug that you turned up. See if there are any other
compiled modules in the system that you can update first.


-- 
Regards,
Ian Clelland
<clell...@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: json serialization question

2011-05-27 Thread Ian Clelland
On Tue, May 24, 2011 at 8:36 AM, Sells, Fred
<fred.se...@adventistcare.org>wrote:

> My code looks like this
>
> records = models.Residents.objects.extra( where=[], params=[...])
> data = serializers.serialize('json', records, ensure_ascii=False,
> fields=('fname','lname', 'pt'))
> return HttpResponse(data)
>
> After experimenting the "ensure_ascii=False" seems to get rid of the
> Unicode prefix which is not used in my work.
>
> which returns
> [
> {"pk": "7", "model": "app.residents", "fields": {"lname": "Mouse ",
> "pt": "0", "fname": "Minnie "}},
> ...]
>
> I was surprised to see the subnode "fields" in the output.  Perhaps I'm
> just old school having does basic cgi with json and pretty much forced
> the format.
>
> 1. However is the above the "best practice" or is there an option to
> strip the meta data.
>

I don't think that anyone would condone this as a 'best practice' -- the
Django serializers are meant to dump django objects, say into session data,
or into database fixtures, and they are really designed to be read by the
deserializers when the object needs to be reconstructed.

If you are passing data from Django to a browser's JavaScript thread using
JSON, then you probably want to either

1. Use an API framework, such as Piston (google: django-piston) or TastyPie
(google: django-tastypie) to handle serialization of outgoing data. These
are very useful if you expect to be receiving data from the browser in the
same format for creating or updating objects, but they can be a lot of
overhead for small applications, so you may want to

2. Write your own serialization. It's quite simple, and Django does an
excellent job of packaging the simplejson library (deferring to the system
installed version, if it's available, and newer than Django's). All you need
to do is something like this:

from django.utils import simplejson as json
...
records = models.Residents.objects.extra( where=[], params=[...])
data = json.dumps(records.values('fname','lname','pt'))
return HttpResponse(data, mimetype='application/json')

records.values(...) should return just the dictionary that you want to use.
json.dumps(...) will convert that into a JSON string, which you can then
return as an HttpResponse.


-- 
Regards,
Ian Clelland
<clell...@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: Email app is breaking long lines, any fix?

2011-05-17 Thread Ian Clelland
On Tue, May 17, 2011 at 1:02 PM, John Crawford <cycl...@speakeasy.net>wrote:

> Actually, upon looking more at the output, it has *both* "utf-8" and
> "us-ascii" as the charset.


Actually, it doesn't. It only has utf-8. The first nine lines of your pasted
output are the actual email headers. Following the blank line is the email
body, which begins with three lines that *look* like headers, but are
actually just part of the message, and any email client would just render
them as text at the top of the message.

(In addition to the blank line, this is alse evidenced by the fact that the
'=' in 'charset='us-ascii'" was escaped as '=3D', as is normal for
quoted-printable-encoded text)


> I'm not sure if this is the result of code
> changes I've made, or I just missed it the first time around - but my
> Django email output now looks like this:
>
> -- MESSAGE FOLLOWS --
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: quoted-printable
> Subject: some_subject
> From: m...@test.com
> To: m...@test.com
> Date: Tue, 17 May 2011 19:58:16 -
> Message-ID: <20110517195816.16624.1004@CRAY>
> X-Peer: 127.0.0.1
>
> Content-Type: text/us-ascii; charset=3D"us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
>
> this is a test of a really long line that has more words that could
> possibl=
> y fit in a single column of text.
>  END MESSAGE 
>
> So although I'm creating a MIMEText object with a plain, "us-ascii"
> string - somewhere, Django is sending a charset of "utf-8". At least
> if I read this correctly.
>
> So does anyone know how to tell Django to *not* send "utf-8"? Thanks.
>

What are you *actually* doing to send this email? It sounds like you are
creating some kind of object and passing that as the body to send_mail,
while send_mail is expecting text, and is just coercing your object into a
string and using that as the message body.

It is definitely possible to tell Django not to use UTF-8 encoding, but you
won't be able to use the send_mail shortcut to do it. You will have to use
an EmailMessage object directly[1]. You should be able to instantiate an
EmailMessage, set the headers yourself, and call send() on it.

(Also, 'text/us-ascii' is not a registered MIME type; you probably want to
say something like 'text/plain; charset=us-ascii')


[1]
http://docs.djangoproject.com/en/1.3/topics/email/#the-emailmessage-class


-- 
Regards,
Ian Clelland
<clell...@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: Encrpting urls to hide PKs

2011-05-12 Thread Ian Clelland
On Thu, May 12, 2011 at 12:29 AM, Wesley Childs <childs.wes...@gmail.com>wrote:

> Why cant you do something like this to avoid exposing data if people are
> guessing primary keys
>
> if request.user == Users.objects.get(id=pk-url):
> Show data
> Else:
> raise 404 or redirect to home page
>
> The above requires a logged in a user but you get the idea of not allowing
> people to start guessing to expose data.
>

You can't do this, in this case, *because* it requires a logged-in user.
Specifically, the OP is looking for a way to authenticate a user based on
their knowledge of a 'secret' URL, but if the URLs are predictable, then
discovering the secrets is trivial. Your solution is fine once the user has
been logged in, although some people would say that it can still give away
too much information*

Honestly, I can think of exactly two ways for the original poster to achieve
his goal (and I've deployed systems using each of these):

1. Sign** the ID with a secret known only to the web server. Put the ID and
the signature in the URL somewhere, and, when the user hits the view, sign
the ID again, and verify that the signatures match. This doesn't hide the ID
at all, but it ensures that nobody can forge a url with a different ID than
the server gave them.

2. Generate a unique token for each record, randomly. Use a UUID, they're
great for that. Then use the token in the URL, and look for the token in the
database when the user comes back to the confirmation view. If your tokens
are actually random, and large enough (say, 64 bits), then anybody trying to
guess them will be wasting their time.


-- 
Regards,
Ian Clelland
<clell...@gmail.com>


* By looking at the database IDs, people can gauge how heavily the system is
being used, or if they see a key for someone else's record, they can
estimate when that record was created, by comparing it to their own data.

** And by sign, I mean HMAC.

-- 
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: Decimal * Float problem

2011-05-11 Thread Ian Clelland
On Wed, May 11, 2011 at 1:14 AM, Colin Corbett <ccorb...@coremed.co.uk>wrote:

> Thanks!  Solved:
>
> In models.py:
>
> class OurProducts(models.Model):
>  code = models.CharField(max_length=60)
>  name = models.CharField(max_length=80)
>  price = models.DecimalField (max_digits=8, decimal_places=2)
>
>  def combined_price(self):
>from decimal import Decimal
>return round(self.price * Decimal(0.65),2)
>

For the sake of anyone searching the group for this issue in the future,
that last method should be:


>  def combined_price(self):

>from decimal import Decimal
   return (self.price * Decimal('0.65')).quantize(Decimal('0.01'))

Python will sensibly throw an exception if you try to create a Decimal from
a float directly, so Decimal(0.65) will not work. Also, the round() function
will turn your carefully calculated decimal value *back* into a float; you
should use .quantize() instead.

-- 
Regards,
Ian Clelland
<clell...@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: 500 message with POST

2011-05-02 Thread Ian Clelland
On Mon, May 2, 2011 at 7:45 AM, Robert Cross <blueb...@gmail.com> wrote:

> I'm a Django newbie and I'm trying to do some minor tests with POST methods
> (I need an automated/scriptable way to get data into my Django database).
> Using the following code
>
> @csrf_exempt
> def posttest(request):
> z=request.POST.get('data', 'no data')
> html="POST TestData supplied was \""
> html=html+z
> html=html+"\""
> return HttpResponse(html)
>
> When I run a test upload it fails:
>
> $ wget --post-data 'data=Something'
> http://localhost:8000/posttest?data=Command
> Line
> --2011-05-02 15:30:03--  http://localhost:8000/posttest?data=CommandLine
> Resolving localhost (localhost)... 127.0.0.1
> Connecting to localhost (localhost)|127.0.0.1|:8000... connected.
> HTTP request sent, awaiting response... 500 INTERNAL SERVER ERROR
> 2011-05-02 15:30:03 ERROR 500: INTERNAL SERVER ERROR.
>
> If I don't supply any post data then it appears to work (301 followed by
> 200 codes, but still gives the expected html).
>
> Any ideas what I'm doing wrong? (Get methods seem to work - but I'd prefer
> not to use them because they're not technically correct for a DB update
> function)
>
>
I'm not sure where the 500 error is coming from -- if you can get wget to
show you the HTTP response, then you should be able to see the actual error
and traceback in there (as long as you have DEBUG enabled, you should get
back a formatted HTML document with the error message in it)

If you can't get the error output, then try at least printing the html
variable before the view function returns. You'll at least know if if gets
that far, or if the error is happening somewhere else. Just watch the
console where your server is running, and you should see the output of any
print statements.

The fact that, on GET, you are getting a 301 first means that the URL that
you are providing is not the correct one for the resource. You probably have
"/posttest/" defined in your urls.py, but you are using wget to access
"/posttest" (no trailing slash). On a GET request, it is perfectly safe to
just issue a redirect to the correct URL, but it is not necessarily safe for
POST requests. I believe that Django will issue the redirect anyway, buy the
user agent is *not* supposed to just blindly post the data to the new URL
without some sort of user interaction.

To eliminate this as a possible error source, try putting the trailing "/"
on the URL in the command line:

$ wget --post-data 'data=Something'
http://localhost:8000/posttest/?data=CommandLine

Then you should get { 'data': 'CommandLine' } in request.GET, and { 'data':
'Something' } in request.POST.

-- 
Regards,
Ian Clelland
<clell...@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: compressing uploaded file

2011-04-20 Thread Ian Clelland
On Wed, Apr 20, 2011 at 1:02 AM, Daniel Gerzo <dge...@gmail.com> wrote:

> On 20.4.2011 2:22, Julio Ona wrote:
>
>> Hi Daniel,
>>
>> you should see:
>> http://docs.python.org/library/bz2.html#module-bz2
>>
>> <http://docs.python.org/library/bz2.html#module-bz2>or
>> http://docs.python.org/library/gzip.html#module-gzip
>>
>
> Hello Juliom, thanks for reply.
>
> I have of course seen both of these before I sent the mail, unfortunately I
> couldn't figure out how to use it on my InMemoryUploadedFile object.
>
>  But basically you should import the compress function from the library
>> and use it.
>>
>> <http://docs.python.org/library/gzip.html#module-gzip>from bz2 import
>>
>> compress
>>
>> [...]
>>
>>
>> def handle_uploaded_subtitles(self, files):
>>for file in files:
>>sub_file = SubtitleFile(file_name=file.name, etc)
>>bz_file = compress(file)
>>
>
> I wish it would be that easy :-)
>
> What you are proposing fails with Exception:
>
> bzfile = compress(file)
> argument 1 must be convertible to a buffer, not InMemoryUploadedFile
>
>
Well, an InMemoryUploadedFile isn't a real file, so I'm not surprised that
that doesn't work. You'll have to pull the data out of it, and compress
that.

Try something like this:

def handle_uploaded_subtitles(self, files):
   for uploaded_file in files:
   sub_file = SubtitleFile(file_name=file.name, etc)
   data = bz2.compress(uploaded_file.read())
   # Here I'm assuming that SubtitleFile.file is a real file object
   sub_file.file.write(data)
   sub_file.file.close()

If your files are large, then you can read them in lines, or in chunks, and
use a BZ2Compressor object to compress them one-at-a-time.

Further, I wasn't able to find a method in the mentioned libraries that
> would make this possible, or at least I didn't figure out how to pass an
> InMemoryUploadedFile to them to compress it.
>
> When I try to do this:
>
> file.write(zlib.compress(file.read()))


Don't do that -- I'm pretty sure that writing a file that you already have
open for reading will produce undefined results.

(Also, I'd try to stay away from using 'file' as a variable name -- it just
hides the built-in file type name, and makes it hard to tell what, say,
file.read refers to)


-- 
Regards,
Ian Clelland
<clell...@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: Debugging a unittest

2011-04-20 Thread Ian Clelland
On Tue, Apr 19, 2011 at 3:44 PM, Thomas Weholt <thomas.weh...@gmail.com>wrote:

> I'm wondering if anybody has a hint on how to debug a unittest, or any
> other piece of code in django, for that matter, using a debugger like
> winpdb?
> I'm trying to to a winpdb manage.py test photo, which runs my unittest
> for my photo app, but winpdb crashes. Are there alternatives? What is
> the best way to do this?


 I don't know about winpdb, but if it's compatible with pdb, then I just do
this:

class ExampleTestCase(TestCase):
def test_something(self):
# some test code
# ...
import pdb; pdb.set_trace()
# ...
# rest of the test code

Then run your tests normally, and the debugger will automatically be invoked
at the 'pdb.set_trace()' line.

To speed things up, you can run
./manage.py test app.ExampleTestCase.test_something

And only the one test that you specify will actually be run.

-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: how to call user-defined database functions through the Django query syntax?

2011-04-20 Thread Ian Clelland
On Wed, Apr 20, 2011 at 8:18 AM, Andrew Dalke <andrewda...@gmail.com> wrote:

> I'm using MySQL and sometimes SQLite as the backend database. Both
> databases let me add user-defined functions. I've made a set of UDFs
> specific to my problem domain, which is chemsitry.
>
> How do I call them from a database query? Currently I'm using a raw()
> call, which made for some rather ugly SQL construction.
>

It sounds like you could do this with a QuerySet.extra() call (
http://docs.djangoproject.com/en/1.3/ref/models/querysets/#extra)

I don't know how you would use those with Q objects, though.

>
> Ideally I would like something like
>
> q = (models.Q(title__icontains="test") &
>   models.Q(structure_smiles = smartsmatch(smarts="[C;!H0]"))
>
>  -or-
>
> q = (models.Q(title__icontains="test") &
>   models.Q(structure_smiles__smartsmatch = "[C;!H0]"))
>
>
> which would get mapped to
>
>title LIKE 'test' AND structure_id = structure.id AND
> oe_matches(structure.smiles, "[C;!H0]")
>
>
You could do something like:
myModel.objects.filter(title__icontains="test").extra(where='oe_matches(structure.smiles,
"[C;!H0]")')

You could encapsulate the extra() call in a function call that annotates a
QuerySet that you pass to it, but it's 'outside' of the ORM at that point.

-- 
Regards,
Ian Clelland
<clell...@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: Unidirectional relations

2011-04-20 Thread Ian Clelland
On Tue, Apr 19, 2011 at 7:28 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

> 2011/4/19 Juan Pablo Romero Méndez <jpablo.rom...@gmail.com>:
> > Is it possible to create unidirectional relations within django's orm?
> >
> > What I mean is a situation where a parent has a children_set of
> > references to children, but the children don't have any reference to
> > the father.
>
> See the documentation for ForeignKey.related_name:
>
> http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name
> .
> In particular, note the part about what `related_name="+"` does.
>

Jacob,
That sounds like it would create exactly the opposite situation from what is
wanted.

class Parent(models.Model):
pass
class Child(models.Model):
parent = models.ForeignKey(Parent, related_name='+')

would give a child a reference to their parent, without the parent having a
child_set attribute.

I think Mike has the right idea; using a separate 1:many table to avoid
explicit fields on the child model, but, of course, SQL being what it is, it
is still possible to construct a query that joins the tables and
reconstructs the link from child to parent.

-- 
Regards,
Ian Clelland
<clell...@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: Using composition in Django

2011-04-16 Thread Ian Clelland
On Sat, Apr 16, 2011 at 1:35 PM, Guevara <eguevara2...@gmail.com> wrote:

> Hello!
> I have two class, Person and employee, i need make a composition for
> this (Prefer composition over inheritance):
>
> class Person(models.Model):
>name = models.CharField(max_length=50)
>date_inclusion = models.DateField()
># others fields
>
> class Employee(models.Model):
>person = models.OneToOneField(Person, primary_key=True)
>address = models.OneToOneField(Address, primary_key=True)
>
>
> The SQL generate is:
>
>
> BEGIN;
> CREATE TABLE "person_person" (
>"id" serial NOT NULL PRIMARY KEY,
>"name" varchar(50) NOT NULL,
>"date_inclusion" date NOT NULL,
> )
> ;
> CREATE TABLE "employee_employee" (
>"person_id" integer NOT NULL PRIMARY KEY,
>"address_id" integer NOT NULL PRIMARY KEY,
> )
> ;
>
>
> This is correct? Should generate the id of the employee?
>

I don't think it's correct -- a database table shouldn't have two distinct
primary keys. It's the "primary_key=True" part of your Employee model fields
that is doing this, and is also stopping an "id" field from being
automatically generated.

If you write Employee like this:

class Employee(models.Model):
   person = models.OneToOneField(Person)
   address = models.OneToOneField(Address)

Then it will generate SQL like this:

CREATE TABLE "employee_employee" (
   "id" serial NOT NULL PRIMARY KEY,
   "person_id" integer NOT NULL,
   "address_id" integer NOT NULL
)
;

which is probably closer to what you're expecting.

-- 
Regards,
Ian Clelland
<clell...@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: Nested admin command problem

2011-04-07 Thread Ian Clelland
On Thu, Apr 7, 2011 at 3:10 AM, Hamdy <hfa...@cloud9ers.com> wrote:
> Hi,
>
> I'm having a case in which I'm making an admin command that takes some
> options
> This's great and works just fine
> the problem appears when trying to call another command from within
> the first
>
> option_list = BaseCommand.option_list + (
>        make_option('--host',
>                             default='127.0.0.1'), )
>
>    def handle(self, *args, **options):
>        # change some settings
>        call_command('test', *args, **options)   # Here's the problem
>        #call_command('test', *args, **options) # This didn't help too
>
> the test command has no --host and thus we get an error that test
> command has no test option
> Any ideas how to overcome this ?

Can you just take 'host' out of the options dictionary?

def handle(self, *args, **options):
self.host = options.pop('host') # 'host' isn't in options anymore
   # do some more stuff
call_command('test', *args, **options)


-- 
Regards,
Ian Clelland
<clell...@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: Using ifnotequal with a list object not working

2011-04-07 Thread Ian Clelland
On Thu, Apr 7, 2011 at 12:25 PM, aaron <aaron.jerl...@gmail.com> wrote:
> Hi there,
> I'm trying to do something quite simple within my html using ifnotequal (dj
> 0.96). The code within my html is as follows:
>             {% ifnotequal {{the_types.0}} "Nothing dude" %}
>                 {{the_types.0}}
>             {% endifnotequal %}

Take out the {{ }} around the variable inside of the {% ifnotequal %}
tag. Those braces are just for inserting the value of the variable
into HTML content, not for referencing it inside of a template tag.

{% ifnotequal thetypes.0 "Nothing dude" %}
...
{% endifnotequal %}
should work.


-- 
Regards,
Ian Clelland
<clell...@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: Seeking Django Counsel when adding a new model using South and a custom field for my ProtectedFileField subclass

2011-03-27 Thread Ian Clelland
On Sun, Mar 27, 2011 at 1:47 PM, Matteius <matte...@gmail.com> wrote:
> add_introspection_rules([], ["^student_portal\.fields
> \.ProtectedFileField"])
...
>  ! Cannot freeze field 'student_portal.assignment.provided_files'
>  ! (this field has class
> classcomm.student_portal.fields.ProtectedFileField)


Without looking too carefully at whether your introspection rules are
correct, the first thing that jumps out at me is that South sees the
field class as "classcomm.student_portal.fields.ProtectedFileField",
while you have registered an introspection rule for
"^student_portal\.fields\.ProtectedFileField".

The "^" at the beginning of your regex anchors the expression to the
start of the string, so it will only match if your class name begins
with "student_portal".

Try changing the regex in your add_introspection_rules call to either:

"student_portal\.fields\.ProtectedFileField" -- removing the "^" so
that it can match anywhere within the string, or

"^classcomm\.student_portal\.fields\.ProtectedFileField" -- preserving
the "^", but adding the "classcomm." that South sees as the start of
the full class name.

-- 
Regards,
Ian Clelland
<clell...@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: Repetition in urls.py

2011-03-24 Thread Ian Clelland
On Thu, Mar 24, 2011 at 12:40 PM, Ryan Osborn <ryan.osbor...@gmail.com> wrote:
> I was just wondering if there was a simple way to condense this as
> with django 1.2 I could add all this in to a dictionary like:
>
> info_dict = {'model': Entry, 'date_field': 'created', 'paginate_by':
> 10}


Can you not set your info_dict just like that, and then rewrite it like this:

YearArchiveView.as_view(**info_dict),name='blog_archive_year'),
url(r'(?P\d{4})/(?P[a-z]{3})/$',


-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: How make CSRF middleware emit html4 rather than xhtml1.0 (closing tags issue) so will validate?

2011-03-14 Thread Ian Clelland
On Mon, Mar 14, 2011 at 10:57 AM, Chris Seberino <cseber...@gmail.com> wrote:
> My Django app's html won't validate because CSRF middleware adds
> hidden
> tags like this...
>
>  name='csrfmiddlewaretoken' value='ebcf3d41f32a70a209e27ef7fdf06d72' />
>
> The only problem is the slash "/>" at the end.
>
> How make Django templates not automatically add hidden tags that won't
> validate?

You have access to a context variable called "csrf_token", which just
contains the actual token string. If you don't like the output of the

{% csrf_token %}

template tag, then just write it yourself in a template. The simplest
way would be to put, in your template, some code like this:





(Note the '{{', '}}' delimiters, rather than '{%', '%}')

A more complicated, but more reusable way to do it would be to write
your own template tag (it's really simple, you can use the CSRF-token
code in django/template/defaulttags.py as a starting point) which
would render whatever markup you need.

-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: How to check if string is in Hebrew

2011-02-28 Thread Ian Clelland
On Sun, Feb 27, 2011 at 3:01 PM, ydjango <traderash...@gmail.com> wrote:
> Hebrew is within the unicode range 0x590 to 0x5ff.
>
> I tried
> if lang_string[0] >= u'0x590' and lang_string[0] <= u'0x5ff':
>
> but it does not seem to work.

That isn't the correct syntax for unicode string literals. What you
are trying to do should look like this:

if lang_string[0] >= u'\u0590' and lang_string[0] <= u'\u05ff':

(See http://docs.python.org/reference/lexical_analysis.html#strings
for all the details on \u, \U, \x and their friends)

Testing just the first character of the string may or may not work for
general input; that depends entirely on your problem (and your users).
If it were me, I would define a utility function like this:

def char_is_hebrew(char):
return char >= u'\u0590' and char <= u'\u05ff'

and then test all of the characters in the string, either with

if any(map(char_is_hebrew, lang_string)):


or

if all(map(char_is_hebrew, lang_string)):


-- 
Regards,
Ian Clelland
<clell...@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: User Profiles?

2011-02-15 Thread Ian Clelland
> user=User.objects.create_user(username=username,email=email,password=password)
>    except django.db.utils.IntegrityError:
>        print 'user exists'
>        user=User.objects.get(username=username)
>    user.firstname=first_name
>    user.lastname=last_name
>    user.save() #make sure we have the user before we fiddle around
> with his name
>    #up to here, things work.
>    user.profile.age=34
>    user.save()

> The question is, why doesn't the age update?

This doesn't do what you are expecting, simply because saving the user
object is different from saving the profile object. (user.save() just
updates a row in the auth_user table, which doesn't affect the
accounts_userprofile table at all.)

The way I would do it is this:

profile = user.get_profile()
profile.age = 34
profile.save()

Try that, and see if it updates the database.

-- 
Regards,
Ian Clelland
<clell...@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: TemplateSyntaxError at /polls/updatepath/ Caught AttributeError while rendering: 'RawQuerySet' object has no attribute 'all'

2011-02-11 Thread Ian Clelland
On Thu, Feb 10, 2011 at 9:10 AM, hank23 <hversem...@stchas.edu> wrote:
> So when I go to build the entries for my drop down list then I would
> iterate over the query results like you suggested and at that point
> where I iterate over the results then I can also set the different
> select option attributes (html option tag attributes - value and
> visible-choice)  to the various values contained in each object
> returned in the queryset. Right?

I don't see why not. Of course, I don't see what your models look
like, either, but you should be able to do something like this:


{% for obj in my_raw_queryset %}
{{ obj.visible_choice }}
{% endfor %}


-- 
Regards,
Ian Clelland
<clell...@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: TemplateSyntaxError at /polls/updatepath/ Caught AttributeError while rendering: 'RawQuerySet' object has no attribute 'all'

2011-02-10 Thread Ian Clelland
all() is a method on a Manager instance, that returns a QuerySet
containing every row in the table, without filtering. It is used
because you can't iterate over a Manager, only over a QuerySet.

As an example, if MyModel is a model, then MyModel.objects is a
Manager. If you tried to do this in python:

for obj in MyModel.objects:
# something

You would see an exception raised. In this case, you need to iterate
over MyModel.objects.all().

A RawQuerySet, though, is already a QuerySet. You can just iterate
over it, and it will just return every row that your SQL produces.
(Actually, that's pretty much all you can do with it, there's no way
for the ORM to add any other filtering or ordering to your custom SQL)

So, instead of trying to call all() on the QuerySet, just iterate over
it -- rather than

{% for obj in my_raw_query_set.all %}

just do

{% for obj in my_raw_query_set %}


On Thu, Feb 10, 2011 at 7:28 AM, hank23 <hversem...@stchas.edu> wrote:
> I'm trying to use raw SQL to retrieve the information that I want to
> display in a dropdown list. Here's the error that I'm getting:
>
> TemplateSyntaxError at /polls/updatepath/
> Caught AttributeError while rendering: 'RawQuerySet' object has no
> attribute 'all'
>
> I'm not sure what this is trying to tell me. I used the same SQL
> syntax that is shown in the documentation at:
>
> http://docs.djangoproject.com/en/dev/topics/db/sql/
>
> Can somebody explain this to me? 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-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.
>
>



-- 
Regards,
Ian Clelland
<clell...@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: csrf cookie security

2011-02-10 Thread Ian Clelland
On Thu, Feb 10, 2011 at 5:21 AM, Lior Sion <lior.s...@gmail.com> wrote:
> It's been a while since I dealt with those things, but what about this
> scenario:
>
> The attacker detects the CSRF code using an attack resembling the
> scenario here:
>
> http://wiki.developerforce.com/index.php/Secure_Coding_Secure_Communications#Secure_Communications_and_Cookies
>
> [to save some time, this is the quote:
>
> Failure to set the Secure flag for security-critical cookies is the
> most common vulnerability in this category. Simply setting a cookie
> over an HTTPS connection does not prevent it from being returned over
> HTTP unless the Secure flag is set. Even if your site does not have an
> HTTP version, malicious parties on the network may be able to steal
> session cookies.
>
> There are several ways to achieve this. For example, the attacker may
> insert references to HTTP URLs to your application into sites that
> your users are likely to visit. Assume your application is 
> https://app.example.com,
> and your users frequent a discussion forum/blog at http://exampleappblog.com.
> ExampleAppBlog allows commenters to include limited HTML in their
> posts, including img tags. A commenter inserts HTML into one of their
> comments like the following:
>
> http://app.example.com/example-logo.png;
> class="external free" title="http://app.example.com/example-logo.png;
> rel="nofollow">http://app.example.com/example-logo.png" />
> When a user authenticated to app.example.com views this comment, their
> browser will fire off a request for example-logo.png over an insecure
> HTTP connection. Since the app.example.com cookie was not set Secure,
> the browser will include the cookie over this connection — exposing it
> to the network.
>
> ]
>
> Once they have the CSRF cookie, they use the site itself (example.com)
> and post malicious code there with the right CSRF.
>
> I agree it's not an easy attack, but why not turning on the secured
> flag for cookies on https?

This is a general attack against cookies; certainly, if an attacker
can steal all of your cookies, and can interfere with your network
connection, he can do a lot, with or without CSRF protection.

More specifically, the attack you present is more relevant to the
session cookie than the the CSRF-token cookie. If an attacker can
sniff your connection, and retrieve the cookies from it, then why not
just grab your session cookie (it's no more or less secure than the
CSRF cookie), and use it to impersonate you on the site? He won't even
need the CSRF token; he can just use any GET request to a page with a
form on it to get a new one.

If you are worried about an attacker who can sniff your network, you
have more to worry about than the 'secure' flag on your CSRF cookies.
You need to make sure that your login credentials (username/password)
are never sent in the clear, that your session cookie is never sent in
the clear, and that essentially your whole site is protected by SSL,
such that a request coming in over plain HTTP, even if properly
authenticated, is still rejected. Once you have this in place, the
secure flag on the CSRF cookie becomes irrelevant. An attacker can't
do any more damage with it than he could by any other means.

-- 
Regards,
Ian Clelland
<clell...@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: csrf cookie security

2011-02-09 Thread Ian Clelland
On Wed, Feb 9, 2011 at 11:51 AM, Brian Craft <bc...@thecraftstudio.com> wrote:
> I thought, rather, that the csrf token was a cookie that was put in a
> hidden form field.

You're absolutely right; I wasn't thinking about that side of the token.

> With firebug or webkit dev tools you can see the django csrf token in
> the cookies. I would also refer you to middleware/csrf.py, where you
> can see it doing the set_cookie.
>
> I thought the security of the csrf token relied on the fact that the
> 3rd party wouldn't know what value to put in the hidden form field.
> The csrf middleware is, I believe, validating the value in the form
> field, against the value in cookie. But when it creates the form, it
> uses the value in the cookie.
>
> If the token is stored in an insecure cookie, it can be sniffed. Then
> I don't understand what prevents the attacker from constructing a
> valid form.

If you want a secure cookie, that means that your entire site (or at
least the form-handling bits) must already be protected by SSL (since
a secure cookie will only be returned over an SSL connection).

The threat model you are proposing, then, sounds like this: There is a
website, running Django, using Django's CSRF protection, in which all
of the form-handling views are only accessible over HTTPS, but there
are other resources in the same domain (or its subdomains) which are
accessible over HTTP.

Further, there is an attacker, who can sniff the unencrypted HTTP
traffic, and can construct an HTML page at a different site (this is
Cross-Site Request Forgery, after all)

A lot of the potential damage seems to be mitigated by another check
in django/middleware/csrf.py, for HTTPS requests only, that inpects
the referer header of the incoming request, to ensure that the browser
was not submitting the form from a different site. To get around that,
the attacker would have to be able to construct a form on the
SSL-protected site (a serious html-injection vulnerability would have
to be present), or cause the request to be submitted over plain HTTP
-- but the site is already HTTPS-only, so there shouldn't be any
form-handling code listening on that port.

Does this threat model correspond to what you're thinking? If so, I
don't see away around the CSRF protection (at least, not one that
involves the victim's browser)


-- 
Regards,
Ian Clelland
<clell...@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: csrf cookie security

2011-02-09 Thread Ian Clelland
On Wed, Feb 9, 2011 at 11:23 AM, Brian Craft <bc...@thecraftstudio.com> wrote:
> I notice that the csrf token is not secure, i.e. the Set-Cookie is
> constructed w/o the "secure" option, so the browser will send it
> in-the-clear. It's trivial, then, for a 3rd party to discover the csrf
> token.
>
> Am I missing something?

The CSRF token isn't a cookie (or at least, it shouldn't be) -- it's a
form field. The security principle behind the CSRF token isn't so much
that it's not discoverable, as much as that an attacker can't
construct a link that gets your browser to submit it to the server.

If you site is under SSL (you're talking about secure-only cookies, so
I presume that this is the case,) then the CSRF token should only
appear in the HTML forms that the server sends to your browser, and
the POST requests that your browser makes back, both of which should
be protected.

If the CSRF token was set in a cookie, then it would be sent with
every single request that the browser made, and it really would be
trivial for an attacker to get you to make a valid request of the web
server, whether he could discover the contents of that cookie or not.
(SSL wouldn't even help; he could construct an https:// link just as
easily.) That's not how it's supposed to be set up, though.

-- 
Regards,
Ian Clelland
<clell...@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: URLField strange error

2011-01-19 Thread Ian Clelland
On Wed, Jan 19, 2011 at 10:37 AM, galago <prog...@gmail.com> wrote:
> Django 1.2.4,
> Python 2.7
> All is coded as it should be. debugger shows error in python code as You
> said. Maybe it will be fixed in the future. Exception is only when i put [ .
> When i put [] all is ok :)

Yes, either a bare '[' or ']' in the URL hostname will trigger this error.

Oddly, the URLValidator in django.core.validators should be catching
the ValueError that is coming back from urllib2; Django should already
be handling this. How are you trying to insert the value? Is this
being handled through a ModelForm, or are you saving the model
manually?

Regards,
Ian Clelland
<clell...@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: URLField strange error

2011-01-19 Thread Ian Clelland
On Wed, Jan 19, 2011 at 6:29 AM, galago <prog...@gmail.com> wrote:
> When I try to insert that string to urlfield: http://asd[d I get strange
> exception:
>
> Invalid IPv6 URL
>
> How to correct it to show message and not error 500?

You will likely need to post some more information: What version of
Django, and what version of Python are you using?

A very quick search suggests that this is a new exception emitted by
Python 2.7; Django's URLField tries to validate the url with an actual
network connection, using Python's urllib2.

The URL you are trying to insert may be just valid enough to get past
the regex checks, and is then parsed by Python as an IPv6 address, and
rejected.

I don't have python 2.7 installed anywhere to check this, but if true,
this may be a bug in Django: Either the regex checks should be
tightened, or the new exception should be caught in the URL Validator.

Without some more info, this is all speculation anyway, though.

Regards,
Ian Clelland
<clell...@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: South introspection doesn't get registrered

2011-01-17 Thread Ian Clelland
On Mon, Jan 17, 2011 at 9:18 AM, OryBand <oryb...@gmail.com> wrote:
> Hello.
>
> I am using a simple custom Model:
>
> from django.db.models import ImageField
> class ImageWithThumbsField(ImageField):
>    def __init__(self, verbose_name=None, name=None, width_field=None,
> height_field=None, sizes=None, **kwargs):
>        self.verbose_name=verbose_name
>        self.name=name
>        self.width_field=width_field
>        self.height_field=height_field
>        self.sizes = sizes
>        super(ImageField, self).__init__(**kwargs)
>
> And this is my introspection rule, which I add to models.py:
>
> from south.modelsinspector import add_introspection_rules
> from lib.thumbs import ImageWithThumbsField
> add_introspection_rules(
>    [
>        (
>            (ImageWithThumbsField, ),
>            [],
>            {
>                "verbose_name": ["verbose_name", {"default": None}],
>                "name":         ["name",         {"default": None}],
>                "width_field":  ["width_field",  {"default": None}],
>                "height_field": ["height_field", {"default": None}],
>                "sizes":        ["sizes",        {"default": None}],
>            },
>        ),
>    ],
>    ["^core/.models/.lib.thumbs.ImageWithThumbsField",])
>
> However, when trying to convert my app (named "core") to south, I get
> "freeze" errors, like the rule wasn't registered:
>
>  ! Cannot freeze field 'core.additionalmaterialphoto.photo'
>  ! (this field has class lib.thumbs.ImageWithThumbsField)
>  ! Cannot freeze field 'core.material.photo'
>  ! (this field has class lib.thumbs.ImageWithThumbsField)
>  ! Cannot freeze field 'core.material.formulaimage'
>  ! (this field has class lib.thumbs.ImageWithThumbsField)
>
>  ! South cannot introspect some fields; this is probably because they
> are custom
>  ! fields. If they worked in 0.6 or below, this is because we have
> removed the
>  ! models parser (it often broke things).
>  ! To fix this, read http://south.aeracode.org/wiki/MyFieldsDontWork
>
> Does anybody know why?

Try changing the last line of your introspection rule, from
>  ["^core/.models/.lib.thumbs.ImageWithThumbsField",])
to something like
 ["^lib.thumbs.ImageWithThumbsField",])

It looks like South is not recognizing your field type, as it is using
a different package name than you are.

It may also need to be something like
'core.models.lib.thumbs.ImageWithThumbsField'
or
'core.models.ImagesWithThumbsField'
depending on how your package is structured.

At the very least, I'm pretty sure that the slashes you have in your
regex are incorrect, and won't ever match.

Regards,
Ian Clelland
<clell...@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: Query Set involving Model Method

2011-01-16 Thread Ian Clelland
On Sun, Jan 16, 2011 at 6:51 AM, Mikhail Korobov <kmik...@googlemail.com> wrote:
> It doesn't work that way. ORM translates you queries to SQL and the DB
> is responsible for filtering. It is not possible to translate
> arbitrary python function to SQL or pass it to DB engine. So you have
> to formulate you query using .filter syntax or raw SQL.

This is absolutely correct. You can't mix python functions with SQL functions.

>
> Another possibility is to denormalize data: add 'complete' field to
> the model and recalculate it on save (or whenever it make sense). This
> is often a good solution and it is better than complex queries in
> terms of performance.

There are some downsides to this method, though: It does take up some
space in the database; it requires some processing every time an
object is updated (and if your calculation involves any related
objects, then you have to do it whenever *they* are updated, as well.)
Additionally, if you ever change those rules, then you have to
recalculate the value of that field for every instance in the
database.

That doesn't mean that it's a bad idea -- I use it all the time -- but
you should at least think about it before doing it.

An alternative, if you want to keep the code simple, and don't mind
that it's less efficient than caching the field value, is to pull out
the values from the database with the ORM, and then filter them in
python:

filter(lambda x: x.complete(), DinnerHost.objects.all())

or even like this:

[x for x in DinnerHost.objects.all() if x.complete()]


>
> On 16 янв, 19:16, rmschne <rmsc...@gmail.com> wrote:
>> Thanks. I'm still messing with this; but don't think it quite what I'm
>> looking for.
>>
>> I want/need the Model Definition function complete() for use at the
>> record level.  I did this as a function since the rules are not based
>> simply on the value of the fields.
>>
>> Ideally, I'd like to have the class DinnerHoseManager(modes.Manager)
>> use the complete() function to help return the query set for where
>> complete()=True.  How to put that into this class?
>>
>> It's not the simple filter. Need a little more complexity to
>> determining "complete" based on the two if statements.
>
> --
> 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.
>
>



-- 
Regards,
Ian Clelland
<clell...@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: Generate a unique username for django.contrib.auth

2011-01-14 Thread Ian Clelland
On Wed, Jan 12, 2011 at 1:11 PM, Micah Carrick <mi...@greentackle.com> wrote:
> I cannot use uuid4().hex because that's 32 characters... I need <30.

uuid4().hex[:30] is almost as random as uuid4().hex

There are no timers, MAC addresses, or other non-random sections in a
UUID4, so taking any 30-character slice from it should get you 120
bits of pure random goodness.

-- 
Regards,
Ian Clelland
<clell...@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: QuerySetManager breakage with r14389

2011-01-12 Thread Ian Clelland
On Wed, Jan 12, 2011 at 6:23 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Thu, Jan 6, 2011 at 5:29 AM, Ian Clelland <clell...@gmail.com> wrote:
>> Hi,
>>
>> I've been using Simon Willison's QuerySetManager[1] pattern for a
>> while now, and since upgrading to Django 1.2.4, it has been breaking
>> when I try to call a method on a RelatedManager constructed from it.
>>
>> There was a change in r14389 (14390 in the 1.2.X branch) which causes
>> this code to break -- where there was a simple delegation before from
>> the RelatedManager to the QuerySetManager to the model, there now
>> appears to be an infinite recursion, with the RelatedManager and
>> QuerySetManager trying to call each other's get_query_set methods.
>>
>> Has anybody seen this before? I am presuming that the change to
>> Django's related.py is correct, and that the QuerySetManager code just
>> needs to be updated to properly support Multi-db, but I don't know
>> where to start fixing it.
>
> Hi Ian,
>
> Sorry for taking so long to get back to you.
>
> No - I haven't seen this before; and I can't see an obvious reason
> that the snippet should have stopped working.
>
> If you want to make sure this is addressed, you should open a ticket
> in Trac. What you are report is an apparent regression in a recent
> changeset, so it would constitute a release-blocking bug for 1.3.

Thanks, Russ --

Looking at the QuerySetManager code, I couldn't tell if it was even
doing the right thing by unconditionally overriding __getattr__, or if
that was an incorrect solution that just happened to work until
related.py was fixed.

I've posted it on Trac, as ticket #15062.

(Glad to know it wasn't just lost in the noise :) )

Regards,
Ian Clelland
<clell...@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-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: Ordering columns in from clause

2011-01-06 Thread Ian Clelland
On Thu, Jan 6, 2011 at 7:35 AM, Vlastimil Zima <vlastimil.z...@gmail.com> wrote:
> Recently I found out that distinct() can not be called on queries that
> are ordered as the result query is kind of
>
> SELECT DISTINCT table.id, table.ordering_column FROM table ORDER BY
> table.ordering_column ASC
>
> In ticket http://code.djangoproject.com/ticket/11568 was said that
> this will not be fixed, bacuse this is intentional behaviour of
> ordering.
>
>
> So code
>
> SomeModel.objects.order_by('ordering_column').values_list('pk')
>
> leads to SQL
>
> SELECT table.id, table.ordering_column FROM table ORDER BY
> table.ordering_column ASC
>
> instaed of simple
>
> SELECT table.id FROM table ORDER BY table.ordering_column ASC
>
> My question is, what is the intention? I could not find out any
> advantage that comes from this kind of query.

It is not valid SQL to order by a column that is not in the result set.

MySQL allows you to do that, but that is a MySQL-specific feature.
PostgreSQL, certainly, does not allow this, and there is no real
advantage gained (aside from a slightly smaller response) by excluding
the ordering column.



Regards,
Ian Clelland
<clell...@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-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.



QuerySetManager breakage with r14389

2011-01-05 Thread Ian Clelland
Hi,

I've been using Simon Willison's QuerySetManager[1] pattern for a
while now, and since upgrading to Django 1.2.4, it has been breaking
when I try to call a method on a RelatedManager constructed from it.

There was a change in r14389 (14390 in the 1.2.X branch) which causes
this code to break -- where there was a simple delegation before from
the RelatedManager to the QuerySetManager to the model, there now
appears to be an infinite recursion, with the RelatedManager and
QuerySetManager trying to call each other's get_query_set methods.

Has anybody seen this before? I am presuming that the change to
Django's related.py is correct, and that the QuerySetManager code just
needs to be updated to properly support Multi-db, but I don't know
where to start fixing it.

Thanks,
Ian


The simplest test case I can get to reproduce this problem looks like
this:

from django.db import models
from django.contrib.auth.models import User
from helpers import QuerySetManager

class TestModel(models.Model):
user = models.ForeignKey(User)
string = models.CharField(max_length=64, null=True, blank=True)
objects = QuerySetManager()
class QuerySet(models.query.QuerySet):
pass

>>> user = User.objects.get(username='testuser')
>>> user.testmodel_set.create(string="test")
Traceback (most recent call last):
  File "", line 1, in 
user.testmodel_set.create(string="test")
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/db/models/fields/related.py", line 423, in create
return super(RelatedManager, self.db_manager(db)).create(**kwargs)
  File "/Users/ian/.virtualenvs/egather/lib/python2.6/site-packages/
django/db/models/manager.py", line 138, in create
return self.get_query_set().create(**kwargs)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/db/models/fields/related.py", line 410, in get_query_set
return
superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line
17, in __getattr__
return getattr(self.get_query_set(), attr, *args)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/db/models/fields/related.py", line 410, in get_query_set
return
superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line
17, in __getattr__
return getattr(self.get_query_set(), attr, *args)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/db/models/fields/related.py", line 410, in get_query_set
return
superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line
17, in __getattr__
return getattr(self.get_query_set(), attr, *args)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/db/models/fields/related.py", line 410, in get_query_set
return
superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line
17, in __getattr__
return getattr(self.get_query_set(), attr, *args)
...
Lots snipped
...
  File "/Users/ian/.virtualenvs/egather/lib/python2.6/site-packages/
django/db/models/fields/related.py", line 410, in get_query_set
return
superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line
14, in get_query_set
return self.model.QuerySet(self.model)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/db/models/query.py", line 33, in __init__
self.query = query or sql.Query(self.model)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/db/models/sql/query.py", line 138, in __init__
self.aggregates = SortedDict() # Maps alias -> SQL aggregate
function
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-packages/
django/utils/datastructures.py", line 97, in __init__
super(SortedDict, self).__init__(data)
RuntimeError: maximum recursion depth exceeded while calling a Python
object

[1] http://djangosnippets.org/snippets/734/

-- 
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: Reading data from database tied to another Django project?

2009-07-15 Thread Ian Clelland



On Jul 14, 8:23 am, Benjamin Kreeger 
wrote:
> I was using PostgreSQL at first, but then I found information about
> reading data across databases only with MySQL, so I'm using MySQL for
> the time being.
>
> Now, I don't have a database set for P1 yet because it's just
> displaying reStructuredText files; if I were to set up that site to
> access P2's database (in P1's settings.py file), would I be able to
> (eek) do raw SQL to get the data to display the way I want? Or would
> there be an easier way to do that WITHOUT raw SQL, and WITHOUT
> duplicating that model declared on P2?

I didn't realise that P1 didn't have a database at all -- if that's
the case, then you can just use the credentials from P2 (the
DATABASE_* lines from settings.py) in P1's settings. You can define
the same models -- it's as simple as installing the same apps that P2
uses, there should be no duplication of code, and you'll have access
to all of the P2 data from P1.

If P1 needs its own database, however, (and you're using MySQL, and
your databases are on the same server), then you can use this patch to
django/db/backends/mysql/base.py (this is based on the 1.0.x branch;
other branches should be similar)

===
--- django/db/backends/mysql/base.py(revision 10742)
+++ django/db/backends/mysql/base.py(working copy)
@@ -143,7 +143,7 @@
 def quote_name(self, name):
 if name.startswith("`") and name.endswith("`"):
 return name # Quoting once is enough.
-return "`%s`" % name
+return ".".join(["`%s`" % name_part for name_part in
name.split(".")])

 def random_function_sql(self):
 return 'RAND()'


That will let you define, in your P1 models, a complete table name
like this:

class Example(models.Model):
... fields ...

class Meta:
db_table = 'p2_database.table_name'

And mysql will get the data from the right database. No raw SQL
required.

Ian
--~--~-~--~~~---~--~~
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: SelectMultiple with Static Choices in admin Interface

2009-07-13 Thread Ian Clelland



On Jul 13, 10:03 am, itodd  wrote:
> Greetings,
>
> I'm trying to use a SelectMultiple with a set of static choices. I'm
> experiencing odd behavior when the number of choices exceeds 10. For
> example, take the following Model and ModelForm:
>
> class Project(models.Model):
>     RECIPIENTS = (
>         (1,'Brad'),
>         (2,'Fred'),
>         (3,'Tom'),
>         ...
>         (12,'Harry'),
>         (13,'Betty'),
>     )
>     recipients = models.CharField(max_length=255,choices=RECIPIENTS)
>
> class ProjectForm(forms.ModelForm):
>     recipients = forms.CharField(widget=forms.SelectMultiple
> (choices=Project.RECIPIENTS))
>
> If I select Harry (12) and Betty (13) then save, the correct list
> appears in the database column: [u'12',u'13']. However, when I edit
> the project in the admin interface, Brad (1), Fred (2) and Tom (3) are
> selected. What seems to be happening is that SelectMultiple is
> selecting 1,2,1 and 3 instead of 12 and 13.

Well, part of the problem is that django is storing the python string
representation of a list in the database, in your CharField. The
SelectMultiple widget is returning a list, and by storing that in a
CharField without any further processing, you are getting the repr()
of that list.

When you look at that in the admin (assuming that you've forced admin
to use a SelectMultiple widget as well,) the value is being passed as
a string (not a list) to the widget for rendering.

> Can anyone offer any advice? I have worked around this by using
> letters instead of numbers but this work-around is less than ideal.

If you use unique letters, rather than numbers, this will appear to
work, since the widget will be looking for single characters within a
string, which will (mostly) work. What should be happening, though, is
that something in your code should be taking the output of the
SelectMultiple widget (from the form) and serializing and
deserializing it properly (I doubt that the string "[u'12',u'13']" is
the most appropriate representation of the recipients field in the
database)

(I say "mostly" in the previous paragragph, because if one of your
choices uses the letter "u", then it may appear to be selected all of
the time, because of the python representation of unicode strings)

You probably want to be excluding the recipients field from the model
form, replacing it with another field which uses the multiple-select
widget. Then you can pre-set the value in the widget before you render
the form, and you can set the proper value for the CharField before
you save the model. In the admin, I would just leave recipients as a
CharField, without trying to force it into a multiple select.

Ian
--~--~-~--~~~---~--~~
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: Nested views and urls patterns declaration order

2009-07-13 Thread Ian Clelland



On Jul 13, 8:48 am, Frédéric Hébert  wrote:
> When I declare the outter view after the inner in urls.py she's never
> been called. It's the inner that's got it.
> (She's called when I reverse the order of declaration, eg the outter
> first)
>
>  I've pasted the code at dpaste :http://dpaste.com/hold/66588/
>
> It's maybe a very stupid problem but I can't see why this happens.

It looks like the regular expressions for your urls aren't anchored to
the beginning of the string.

In your 'bad' situation, a url like "ue/reservations/xyz" gets matched
by the first regex, and passed to view_list_reservation (your inner
view), rather than being passed to your outer view, as you would like.

Try adding a '^' character to the front of your regular expressions,
and see if the requests are passed to the proper views.

Ian

--~--~-~--~~~---~--~~
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: Reading data from database tied to another Django project?

2009-07-10 Thread Ian Clelland

On Jul 10, 12:37 pm, Ben Kreeger  wrote:
> How do I go about accessing that data from P2's database? Do I need to
> create a model in P1 and bind it to a certain table in P2's database?
> If that's the case, how do I specify access credentials for that
> database? Is that in settings.py?

If the two projects live in completely separate databases, then there
is no easy way to do that (yet -- there's a GSoC project being
actively worked on by Alex Gaynor to provide multi-database support in
Django)

In a similar situation, where both projects had a database on a common
mysql server, I managed to do this with a one-line change to the
Django mysql backend, which allowed me to specify a table in the
model's Meta class as "database.table" -- this only works because
MySQL allows you to access tables in one database from a connection to
another, as long as your credentials are valid for both.

Another (mysql-only, unfortunately) solution is to run mysqlproxy in
front of your P2 database, and have it direct requests for P1 tables
to the P1 database server. You would have to be careful to avoid any
sort of queries that tried to join the tables from the two databases
together, though -- avoiding foreign keys from P1 models to P2 models
should be enough.

Ian
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Combining filters on related models

2009-07-09 Thread Ian Clelland

I'm trying to construct a query which combines two filters on a
related model, and I'm having no luck. Hopefully somebody can see what
I'm doing wrong, and point me in the right direction.

I'd like to be able to specify two exclude criteria on a related
model, and have both criteria apply to the same related object. I know
that the QuerySet.exclude() method, if given multiple parameters, will
AND them all together, and exclude objects that satisfy all of the
criteria. However, if the parameters refer to related models, then two
parameters in an exclude() call can apply to different related
objects, both related to the same parent object.

To be more specific, I'd like to be able to pull a list of
BillingAccount objects which do not have a "Payment Received" event
logged in the last 45 days. I have a BillingAccount model, and a
BillingEvent model that is related to it:

class BillingEvent(models.Model):
date_created = models.DateTimeField(auto_now_add=True)
date_modified = models.DateTimeField(auto_now=True)
event_time = models.DateTimeField()
billing_account = models.ForeignKey(BillingAccount)
action = models.IntegerField(choices=BILLING_EVENT_CHOICES)

My instinct is to construct a query like this:

BillingAccount.objects.exclude(billingevent__action=12,
billingevent__event_time__gte=datetime.datetime.now()-
datetime.timedelta(days=45)))

(useless trivia: 12 is the numeric code for "Payment Received" in the
choices field)

Unfortunately, this excludes all of the accounts which have any
Payment Received events ever, and all of the accounts which have any
events at all in the last 45 days.

The SQL that django is producing looks like this: (from
django.db.connection.queries)
SELECT `billing_account`.`id`,
 `billing_account`.`customer_id`,
 ... more fields ...
FROM `billing_account`
WHERE NOT (
`billing_account`.`id` IN (SELECT U1.`billing_account_id` FROM
`billing_event` U1 WHERE U1.`action` = 12 )
   AND `billing_account`.`id` IN (SELECT U1.`billing_account_id` FROM
`billing_event` U1 WHERE U1.`event_time` >= 2009-05-25 15:23:45)
)

What I would like to see is a where clause like this:

WHERE NOT (
`billing_account`.`id` IN (SELECT U1.`billing_account_id` FROM
`billing_event` U1 WHERE U1.`action` = 12 AND U1.`event_time` >=
2009-05-25 15:23:45)
)

Is there any way to construct such a query, without resorting to raw
SQL? I've tried it a couple of ways with Q objects, with the same
results... I'm using django 1.0, so I haven't investigated F objects
at all, but I'm willing to upgrade if that's what it takes :)

Thanks,
Ian

--~--~-~--~~~---~--~~
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: trailing slash added to passed form data

2007-04-13 Thread Ian Clelland

On 4/13/07, Tipan <[EMAIL PROTECTED]> wrote:
> I am passing a parameter from a template to an inclusion tag {%
> show_tag  %}. This  value is then returned from the inclusion
> tag defintion in a dictionary (return {'form':form, 'value':id}) to
> render the form for use in a hidden field ( name="xyz" value={{ value }}/>
>
> When I view the html source in the browser it shows a "/" after the
> number e.g.  "6/" This is also passed to the Form when posted. It's
> causing the Form to fail on the is_valid function.

If your hidden input field is exactly like this:


it would seem to me that the "/" in "/>", which closes out the tag,
could be interpreted by the browser as part of the value, rather than
part of the HTML tag. I would try putting the value in quotes, and
leaving at least one space between the value and the "/" character.

Something like this:


would be valid XHTML. If you don't care at all about XML conformance,
you could also just get rid of the "/" and have


which is valid HTML, but not XHTML.

Regards,
Ian Clelland
<[EMAIL PROTECTED]>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



  1   2   >