[Announce] Django security releases issued

[Jacob Kaplan-Moss]

Today we've issued releases to remedy three security issues reported to us.

Affected versions are Django 1.4, Django 1.5, Django 1.6 and the Django 1.7
beta.

Full details and download information are on the Django project weblog:

https://www.djangoproject.com/weblog/2014/may/14/security-releases-issued/

Thanks!

Jacob

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

[ANNOUNCE] Django 1.6.2 and Django 1.7a2

[Jacob Kaplan-Moss]

Hey y'all --

We've just released Django 1.6.2, the latest bugfix release in the 1.6
series, and Django 1.7a2, the second alpha preview of the upcoming 1.7
release.

As usual, more details are available on the blog:


https://www.djangoproject.com/weblog/2014/feb/06/django-162-and-django-17a2-released/

And you can snag the releases from
https://www.djangoproject.com/download/and from PyPI.

Enjoy!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK8PqJEtMLZ8f%3Dr_NQOexecdZkg73hESb09ZG%2B5onbSYOxCWig%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANNOUNCE] Django 1.6.1 released

[Jacob Kaplan-Moss]

Hey folks --

We've just released Django 1.6.1, a bugfix release for last month's Django
1.6 release.

More details are in our blog post:

https://www.djangoproject.com/weblog/2013/dec/12/django-161/

and in the release notes:

https://docs.djangoproject.com/en/1.6/releases/1.6.1/

Enjoy!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK8PqJE%3DnncRakEQ7c6f%2BBXWUJH0awY843s_quUbK7JLit-qEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Security Advisory: ImageField abuse

[Jacob Kaplan-Moss]

Hi folks -

We've just published a short security advisory about ImageFields:

https://www.djangoproject.com/weblog/2013/dec/02/image-field-advisory/

ImageField expects a valid image file, but depending on your app it may
allow uploads on non-image content, such as HTML or JavaScript.
Unfortunately, we cannot offer a solution in Django itself. Rather, you
need to take some steps in how you serve static files in order to mitigate
this type of attack. These steps are now outlined in our security guide:


https://docs.djangoproject.com/en/dev/topics/security/#user-uploaded-content

We recommend that if you allow image uploads that you check your server's
configuration against the above guide.

Jacob

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

[Announce] Expected djangoproject.com downtime tomorrow, Oct 18, starting 20:00 UTC

[Jacob Kaplan-Moss]

Hi folks -

We'll be doing some work on djangoproject.com (and associated sub-sites)
tomorrow, starting around 20:00 UTC. Expect some downtime, possibly as long
as an hour or so, starting around then.

During the downtime, as usual, you can find a mirror of Django's
documentation on Read the Docs: http://django.readthedocs.org/en/latest/.

Thanks!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK8PqJGpj3Jv%2BP0Zqj6u0Q4RuhfYJYniNKk%3DWxjV5mimx0Wn4A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Does Model.save() write back all the field values?

[Jacob Kaplan-Moss]

It's not a bug; that is by design.

However, it's not perfect, so in 1.5 we added update_fields:
https://docs.djangoproject.com/en/1.5/ref/models/instances/#specifying-which-fields-to-save

Jacob


On Wed, Aug 14, 2013 at 7:01 AM, Dong Wang  wrote:

> Hi all,
>
> I'm using Django 1.4.2. Please let me start my question by an example:
>
> books = Book.objects.filter(published=False)
> for book in books:
>  book.published=True
> book.save()
>
> I would think this small snippet of code will only update the "published"
> field, but actually it write all the cached field values back to the
> database.
>
> Is it a bug or designed to be this way?
>
> Thanks
> --
> Dong Wang
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

[ANNOUNCE] Security releases issued (1.4.6, 1.5.2, 1.6b2)

[Jacob Kaplan-Moss]

Hi folks --

Today the Django team is issuing multiple releases -- Django 1.4.6, Django
1.5.2, and Django 1.6 beta 2 -- as part of our security process. These
releases address two cross-site scripting (XSS) vulnerabilities: one in a
widget used by Django's admin interface, and one in a utility function used
to validate redirects often used after login or logout.

While these issues present limited risk and may not affect all Django
users, we encourage all users to evaluate their own risk and upgrade when
possible.

More details can be found on our blog:


https://www.djangoproject.com/weblog/2013/aug/13/security-releases-issued/

As a reminder, we ask that potential security issues be reported via
private email to secur...@djangoproject.com, and not via Django's Trac
instance or the django- developers list. Please see
https://www.djangoproject.com/security for further information.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Security Advisory: BREACH and Django

[Jacob Kaplan-Moss]

Hi folks --

At last week's Black Hat conference, researchers announced the BREACH
attack (http://breachattack.com/), a new attack on web apps that can
recover data even when secured with SSL connections. Given what we know so
far, we believe that BREACH may be used to compromise Django's CSRF
protection. Thus, we're issuing a security advisory so that our users can
defend themselves.

You can read more details, including how the steps you can take to prevent
yourself against this attack, on our blog:

https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/

We plan to take steps to address BREACH in Django itself, but in the
meantime we recommend that all users of Django understand this
vulnerability and take action if appropriate.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

ANNOUNCE: Django 1.6 beta 1 released

[Jacob Kaplan-Moss]

Hi folks --

I'm pleased to announce that we've just released Django 1.6 beta 1,
the second in our series of preview releases leading up to Django 1.6
(due in August).

More information can be found on our blog:


https://www.djangoproject.com/weblog/2013/jun/28/django-16-beta-1-released/

And in the release notes:

https://docs.djangoproject.com/en/dev/releases/1.6/

Thanks!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

ANNOUNCE: Django 1.6 alpha 1 released

[Jacob Kaplan-Moss]

Hi folks --

I'm pleased to announce that we've just released Django 1.6 alpha 1,
the first in our series of preview releases leading up to Django 1.6
(due in August).

More information can be found on our blog:

https://www.djangoproject.com/weblog/2013/may/26/django-16-alpha-1/

And in the release notes:

https://docs.djangoproject.com/en/dev/releases/1.6/

Thanks!

Jacob

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

Re: djangoproject.com is down

[Jacob Kaplan-Moss]

Hi folks -

Looks like we're back.

FTR, the cause was an issue with our hosting provider, more here:
http://status.mediatemple.net/maintenances/3148-emergency-maintenance-multiple-dvve-hostservers-rebooted/.
I'm going to look into adding a bit more redundancy so that we're more
resilient against any future outages like this.

Thanks for your patience!

Jacob

On Tue, May 14, 2013 at 5:53 PM, Jacob Kaplan-Moss  wrote:
> FYI - djangoproject.com is currently down, I'm investigating and I'll
> try to have it back up ASAP.
>
> In the meantime, if you need to get to the docs, you can hit up the
> ReadTheDocs mirror: http://django.rtfd.org/
>
> Thanks for your patience,
>
> Jacob

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

djangoproject.com is down

[Jacob Kaplan-Moss]

FYI - djangoproject.com is currently down, I'm investigating and I'll
try to have it back up ASAP.

In the meantime, if you need to get to the docs, you can hit up the
ReadTheDocs mirror: http://django.rtfd.org/

Thanks for your patience,

Jacob

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

[ANN] Django 1.5.1 released

[Jacob Kaplan-Moss]

Hi folks --

We've just released Django 1.5.1, a bug fix release that cleans up a
couple issues with last month's 1.5 release.

The biggest fix is for a memory leak introduced in Django 1.5. Under
certain circumstances, repeated iteration over querysets could leak
memory - sometimes quite a bit of it.

For more details, see our announcement:

https://www.djangoproject.com/weblog/2013/mar/28/django-151/

Thanks for using Django!

Jacob

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

Goodbye, Malcolm

[Jacob Kaplan-Moss]

Hello fellow Djangonauts,

We have difficult news: Malcolm Tredinnick has passed away.

Malcolm was a long-time contributor to Django, a model community member,
a brilliant mind, and a friend. His contributions to Django — and to
many other open source projects — are nearly impossible to enumerate.
Many on the core Django team had their first patches reviewed by him;
his mentorship enriched us. His consideration, patience, and dedication
will always be an inspiration to us.

To say we'll miss him is an understatement.

Our thoughts are with Malcolm's friends, colleagues, and family at this
difficult time.

This came as quite a shock, and we're still sorting out details. We'll
update our blog,
https://www.djangoproject.com/weblog/2013/mar/19/goodbye-malcolm/,
once we know the details of how you can express your condolences to
Malcolm's friends and family.

— The Django Core Team

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

ANNOUNCE: Django 1.4.5, 1.3.7 released, fixing packaging problems

[Jacob Kaplan-Moss]

Hi folks --

We've released two new releases today -- Django 1.4.5 and Django 1.3.7
-- that correct packaging problems in yesterday's security releases.
There's no new code; just a packaging fix.

For more details, see
https://www.djangoproject.com/weblog/2013/feb/20/updated-releases-issued/.

Sorry about the mixup!

Jacob Kaplan-Moss

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

Re: django user model json

[Jacob Kaplan-Moss]

Hi Anderson --

First, I need to point out something:

On Fri, Feb 8, 2013 at 2:07 PM, Anderson  wrote:
>  'password':
> u'pbkdf2_sha256$1$ObXZ2yN3HATp$3ADUPZrzdvQCkPdJPCakfzILAIF8lPbKgAZLiXm54UI=',

You just posted a password -- yours or one of your users -- on a
public mailing list.

PLEASE RESET THIS PASSWORD IMMEDIATELY. Also if this "activation_key"
is anything sensitive, you should scrub it right away. Django uses a
one-way hashing algorithm that partially protects you against leaking
passwords, but given enough time an attacker could reverse what you
just posted.

So once again, you need to reset that password immediately. If it's a
password you use elsewhere, you should reset it everywhere you use it.
If it's one of your users' passwords, you should notify them
immediately.

Sorry if this comes across as harsh, but the consequences here are
potentially disastrous, and I want to make sure you get the severity
and respond immediately.

Now, as to the issue at hand: I think the answer depends on what
version of Django you're using:

* If this is 1.4, this is probably "correct" at least according to
what Django thinks. When you subclass User you're actually creating a
relationship, not a subclassed model, so Django's only serializing the
local fields on your subclass, not following the relationship.

* If this is 1.5, and you're trying to create a custom User model,
you'll want to subclass AbstractBaseUser instead of User; see
https://docs.djangoproject.com/en/dev/topics/auth/customizing/#substituting-a-custom-user-model
for more details.

Thanks, and again - sorry to be harsh on the security stuff. But it's important!

Jacob

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

FYI: Scheduled downtime on djangoproject.com Thursday night

[Jacob Kaplan-Moss]

Hey folks --

MediaTemple, our hosting provider for djangoproject.com, is going to
be taking our server offline Thursday night while they give us more
RAM.

The window for downtime is some time between 9PM and 4AM, though the
actual downtime itself should be less than an hour.

Since most people use the site for documentation, I'll remind you that
you can always find a mirror of Django's documentation on Read the
Docs: http://django.readthedocs.org/.

Thanks!

Jacob

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

Re: Website Documentation Search broken?

[Jacob Kaplan-Moss]

On Sat, Dec 17, 2011 at 12:30 AM, kenneth gonsalves
 wrote:
> thanks for the info - the search *has* improved, for example a search
> for get_FOO_display used to fail, it now succeeds. But I still need
> ddg's site search for multiword searches.

Can you be a bit more specific? If there's a bug I'd like to fix it,
but I'm not having any issues with "multiword searches"; for example:

* https://docs.djangoproject.com/search/?q=form+wizard&release=5
* https://docs.djangoproject.com/search/?q=auth+middleware&release=5
* https://docs.djangoproject.com/search/?q=database+routers&release=5

Jacob

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

Re: Website Documentation Search broken?

[Jacob Kaplan-Moss]

On Wed, Dec 14, 2011 at 8:36 PM, kenneth gonsalves
 wrote:
> it is using the default sphinx search which is limited to one word
> searches.

That's true of the documentation you build locally, but the search on
docs.djangoproject.com uses Haystack with the Xapian search engine.
It's a proper search engine -- just not tuned perfectly.

Jacob

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

Re: Website Documentation Search broken?

[Jacob Kaplan-Moss]

On Wed, Dec 14, 2011 at 10:21 AM, Torsten Bronger
 wrote:
> creecode writes:
>
>> I can't say for sure but for some time it seems to me that
>> searching has become more difficult.  I can't put my finger on any
>> specifics.  I have found that some phrases that are in my browser
>> form field cache I've used in that past no longer return results.
>> And I'm almost certain some of them were previously successful.

Ugh, I'm sorry. If you take some notes on what those searches are --
which ones aren't returning results you'd expect -- and let me know I
can tweak it.

> I *think* (though I'm really not sure) that the search used to work
> through Google.  Be that as it may, it used to be significantly
> better.  Were there legal problems with the old search?

No, not legal problems; technical -- I had all sorts of problems with
Google's search. You can't tweak it at all -- if you don't like what
you get, tough. It also would go down from time to time, and there was
never any help, ETAs, or info about when it'd be back up. Since it
works off a spider it'd pick up stuff that isn't content -- searching
for "documentation", for example, was useless since that word appears
in the nav. I could go on, but basically Google's search was a PITA.

So I may have taken a step backwards switching away from Google, but
now the control is in our hands -- we can tweak, tune, and otherwise
make it work better. If you want to help, see
https://github.com/django/djangoproject.com and look in
django_website/docs; it's built using Haystack.

> If I searched for "queryset api", the first result was, well, the
> QuerySet API.  Now, it is the fifth.  With just "queryset", it is
> even position 9.

Thank - I'll look into that particular search and see if I can boost
the right document to the top. If you find more like that drop a list
into this thread and I'll take a look.

Jacob

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

Re: Newbie question - if I add "on delete cascade" to a foreign key on my MySQL db

[Jacob Kaplan-Moss]

On Tue, Dec 13, 2011 at 7:22 PM, Mike  wrote:
> will I still be able to use Django's ORM?

Yes, please see
https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.on_delete
and in particular DO_NOTHING.

Jacob

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

Re: Alternative to the .using() method

[Jacob Kaplan-Moss]

On Tue, Oct 11, 2011 at 3:47 PM, Sells, Fred
 wrote:
> I'm using a MySQL database and one table resides in a separate database
> than all the others.  It's a generic logging table.
>
> I understand the use of the .using() method, but I wonder if there is a
> way to specify the alternative model in the model definition so I don't
> have to depend on remembering to add the .using() method in any usage.
>
> I could create a view in mysql and make the model "unmanaged" but was
> wondering if there is a more pythonic way?

Indeed there is: what you're looking for is called a "database
router", and you can find documentation here:
https://docs.djangoproject.com/en/dev/topics/db/multi-db/#automatic-database-routing

In your particular case, you'll implement something very similar to
the first example presented there: if the app is your logging app, use
the logging connection; otherwise, use the default connection.

Jacob

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

Re: Why can't "directly" change array elements of model objects in Django shell?

[Jacob Kaplan-Moss]

On Fri, Oct 7, 2011 at 10:30 AM, Chris Seberino  wrote:
>
> I've noticed that this doesn't often work in Django shell...
>
> x = MyModel.objects.all()
> x[3].some_field = "new value"
> x[3].save()
>
> Rather, I must often do this...
>
> temp = x[3]
> temp.some_field = "new value"
> temp.save()
>
> *Sometimes* the first works and I don't know why.

This is because `MyModel.objects.all()` isn't a list; it's a QuerySet.
That is, `MyModel.objects.all()` *doesn't* hit the database until you
say `x[3]`, at which point Django performs a query with a LIMIT and
OFFSET to just select that 3rd item. The entire list is never fetched.

See 
https://docs.djangoproject.com/en/dev/ref/models/querysets/#when-querysets-are-evaluated
for more details.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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.delete() ON DELETE ...

[Jacob Kaplan-Moss]

On Tue, Sep 27, 2011 at 8:30 AM, Thomas Guettler  wrote:
> it seems, that the django ORM can only do deletes which result in a lot
> of SQL-Queries to do "on delete cascade" in python code.
>
> https://docs.djangoproject.com/en/1.3/ref/models/querysets/#delete
>
> Is there a way to leave this up to the database?

I believe you're looking for `on_delete=DO_NOTHING` -- see
https://docs.djangoproject.com/en/1.3/ref/models/fields/#django.db.models.ForeignKey.on_delete.
This'll leave any cascading (or whatever) up to the database.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 solve MultiValueDictKeyError

[Jacob Kaplan-Moss]

On Wed, Sep 21, 2011 at 5:43 AM, Tom Evans  wrote:
> On Wed, Sep 21, 2011 at 11:33 AM, Kayode Odeyemi  wrote:
>> Hello friends,
>>
>> I don't know why Django is so unstable.
>
> I don't know why you cross posted this to django-developers.

Tom, the snarky tone is un-called-for and not OK. Cross-posting is
against our normal standards, but there's not reason for Kayode to
have known that. Please try to be nice when telling people about our
community standards.

And Kayode: I think you'll find you have a lot more luck getting your
questions answered if you're polite and don't insult the work of a
bunch of volunteers. Calling Django "unstable" is a really bad way to
motivate the people who wrote it to try to help you out.

Remember folks: at the other end of that email is "a real person, a
lot like you" (http://sivers.org/real).

Jacob

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

Re: refreshing a page loaded via POST

[Jacob Kaplan-Moss]

On Wed, Sep 14, 2011 at 2:12 AM, mohammed safeer.mtp
 wrote:
> if a user hits “Refresh” on a page that was loaded via POST, that request is
> be repeated.
> is there any remedy for this problem??

No, you can't prevent a web browser from re-POSTing forms.

What you can do is prevent the browser from ever staying on a
POST-generated page: the standard best practice is a technique called
"Post/Redirect/Get": see
http://en.wikipedia.org/wiki/Post/Redirect/Get for a high-level
description.

In Django, this translates to view functions that look like::

from django.shortcuts import redirect, render

def my_post_view(request):
if request.method == 'POST'
# do something here...
return redirect('some_other_view')
else:
# the request was a GET, so render a template:
return render(request, 'some/template.html')

The key part here to get is that you should always issue a redirect
after a successful POST request.

Jacob

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

Re: Alter the list of fields returned by a queryset without turning them into strings?

[Jacob Kaplan-Moss]

On Mon, Sep 12, 2011 at 8:41 PM, Joshua Russo  wrote:
> Do I just need to do a little more pre-processing in the view or can I
> accomplish what I'm trying to do?

The method you're looking for is ``only()`` (or perhaps its cousin,
``defer``): 
https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.only.

``only()`` takes a list of fields like ``values()``, and constrains
the SELECT clause similarly, but instead of returning a dictionary
returns a model instance, so things like the FileFile objects work
correctly.

Do note that if you use ``defer()``/``only()`` and the access a field
*not* in the select list Django will go perform another query for you,
thus making things less efficient. So only reach for ``only()`` when
you know you're only accessing the specific named fields (as it looks
like you are in your example).

Good luck,

Jacob

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

Re: Testing reusable apps

[Jacob Kaplan-Moss]

On Fri, Sep 2, 2011 at 9:16 AM, Tomek Paczkowski  wrote:
> Hi, I cannot find any good source on how test reusable apps. I poked around
> and found out that people (django-registration, south) tests on blank
> project.
> This seems kind of wrong having to make some outside directory to be able to
> run tests.
> Isn't there any better way?

I think so: I like to use the testing mechanism in
setuptools/distribute and run tests via `python setup.py test`.

Eric Holscher wrote about the approach:
http://ericholscher.com/blog/2009/jun/29/enable-setuppy-test-your-django-apps/.

A good example in some code I've written is
https://github.com/revsys/django-fack. The important parts are in
setup.py, which does::

...
test_suite = "fack._testrunner.runtests",
tests_require = ["mock"],
...

So then fack/_testrunner.py is the test harness itself.

You also might want to check out the tox.ini there too. Tox
(http://tox.rtfd.org/) automates testing against multiple Python
versions (and other types of variable dependencies) and can smooth out
some of the steps in getting quality repeatable testing working.

Jacob

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

Re: HttpResponseRedirect adds hostname?

[Jacob Kaplan-Moss]

On Tue, Aug 23, 2011 at 4:01 PM, Jacob Kaplan-Moss  wrote:
> However, I believe it's not actually Django doing the rewriting.

Scratch that: I'm wrong. Actually, Django *is* doing the re-writing:
see 
https://code.djangoproject.com/browser/django/trunk/django/http/utils.py#L11.

Still, the point stands that it's necessary -- standards and all that
-- and that you should be fixing it in your proxy layer.

Jacob

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

Re: HttpResponseRedirect adds hostname?

[Jacob Kaplan-Moss]

On Tue, Aug 23, 2011 at 3:50 PM, Roy Smith  wrote:
> Why does it do this?  It seems like it should just take the string I passed 
> it and stick that into the header, no?

No - that might seem intuitive, but it's incorrect. The HTTP standard
specifies that the Location header should contain an absolute URI (see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30), so
Django's got to add one.

Practically, most web browsers correctly support relative URIs in
Location headers, but there're a lot more to consuming HTTP than just
browsers (spiders/crawlers, API clients, testing utilities, ...).

However, I believe it's not actually Django doing the rewriting. if
you peer through the implementation of HttpResponseRedirect
(https://code.djangoproject.com/browser/django/trunk/django/http/__init__.py#L689),
you'll see that i there's nowhere in that code path that's munging the
location header. The munging is I think being done by whatever web
server you're using (Apache? Nginx? It's hard to tell from your
description; you just say "Django on port 9200"), and that's where
you'd need to go to fix it. In Nginx, for example, I sometimes need to
mess with the proxy_redirect directive
(http://wiki.nginx.org/HttpProxyModule#proxy_redirect) to fix
situations like this.

Hope that helps,

Jacob

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

Re: Cascading Deletes on ManyToManyField

[Jacob Kaplan-Moss]

On Wed, Aug 17, 2011 at 6:12 AM, Jeremy Keeshin  wrote:
> I have an Item model that has many Tags. If I delete a Tag, I want to make
> sure the related Items are not deleted. I tested this out on my local
> database, and it seems that there are no cascading deletes with many to many
> fields. However, I previously deleted data accidentally with ForeignKeys
> because I did not understand cascading deletes, so I just want to make
> sure.

Yes, this is correct -- foreign keys cascade deletes by default; many
to many fields don't.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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.3 admin added methods login requirement

[Jacob Kaplan-Moss]

On Fri, Aug 12, 2011 at 10:32 AM, Chris Fraschetti
 wrote:
> I believe that in earlier versions of django if you added a view
> method to an admin, and extended the get_urls method that because it
> was under the admin it would automatically require at least a log in
> (user.is_authenticated()=True.  I have been working with Django 1.3
> and have noticed that this is no longer the case?  Has anyone
> experienced this and is there a solution such as a decorator to use
> since login_required will not work with methods.

I don't believe admin views have ever been automatically protected. In
any case, you'll need to use the admin site's ``admin_view``
decorator. See 
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_urls
for details.

Jacob

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

Re: Calculation for each object in a QuerySet

[Jacob Kaplan-Moss]

On Fri, Aug 5, 2011 at 1:49 PM, nixlists  wrote:
> I need a view where for every row returned from Claim I make a
> calculation based on quantity from the Claim, rebate_pct and wac. Is
> it possible to write a model method that would access these fields
> from the other tables?

If I was in your shoes, I'd use Claim.objects.raw() and just write a
raw SQL query (see http://django.me/raw).

Jacob

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

Re: Calculation for each object in a QuerySet

[Jacob Kaplan-Moss]

On Thu, Aug 4, 2011 at 2:14 PM, nixlists  wrote:
> How one would approach this? Do I iterate over the whole QuerySet,
> adding a calculated value to each object? What about pagination as
> done in the generic methods?

Well, without more details about your model(s) and what calculation
you'd like to make it's impossible to give you a specific answer.
However, you may want to take a look at Django's
aggregation/annotation commands (http://django.me/aggregation) and see
if that helps.

If not, perhaps you could share more details? That'll probably help
people help you.

Jacob

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

Re: Satchmo, the bloated manatee

[Jacob Kaplan-Moss]

Hi Bobby --

I'm quite sorry if you took my words as a threat. Such wasn't my
intent -- at all. I'm simply trying to make clear certain community
expectations. You're completely right that banning would be wildly
inappropriate, and I certainly wasn't suggesting that.

The Django community has historically been known as a friendly,
accepting, professional one free of the usual flamewars that crop up
on free software. I really appreciate your help in keeping it that
way. I think we can all agree that a helpful, welcoming community is
something to be proud of.

That's the last I've got to say on the matter; at this point we're
basically going in circles. I hope I made my point clear enough. If
not, please feel free to contact me off-list so everyone else can get
back to talking about software.

Thanks!

Jacob

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

Re: Satchmo, the bloated manatee

[Jacob Kaplan-Moss]

On Thu, Jul 28, 2011 at 11:16 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Hold on, we are in danger of restricting the freedom of speech on this
> mailing list.

There is no right to free speech on a mailing list.

We already restrict what's allowed on this list. Beekeeping, wool
socks, hand grenades and a nearly infinite collection of topics are
declared off-topic. Similarly, we have certain community standards --
politeness among them -- and we can and will enforce them.

If you'd like to have an anything-goes forum where insults and flames
are tolerated then I encourage you to start your own. Around here, I
expect a certain level of decorum and I will enforce it.

Jacob

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

Re: How do I change my user password on Django's bug tracker?

[Jacob Kaplan-Moss]

On Tue, Jul 26, 2011 at 7:07 AM, cool-RR  wrote:
> How do I change my user password on Django's bug tracker?

https://www.djangoproject.com/accounts/password/change/

If you've forgotten your password, see
https://www.djangoproject.com/accounts/password/reset/.

Jacob

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

Re: Satchmo, the bloated manatee

[Jacob Kaplan-Moss]

On Thu, Jul 28, 2011 at 7:15 AM, Bobby Roberts  wrote:
> satchmo has become a bloated manatee of a codebase.

Hey, this isn't OK. I can tell you're frustrated, but insulting other
people's work isn't acceptable around here. You should realize there
are real people, just like you, on the other side of these insults.
Attacking them isn't nice, and won't get you the help you need.

In general, you'll find that you'll get a lot more help if you're
polite. On this particular forum, not being polite isn't acceptable,
so if you insist on insults you'll need to find somewhere else to air
them.

Thanks.

Jacob

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

Re: Changes from 1.2.5 to 1.4 pre-alpha?

[Jacob Kaplan-Moss]

On Fri, Jul 22, 2011 at 4:36 AM, Rodney Topor  wrote:
> I've been away from Django for over 6 months.  Previously I was using
> 1.2.5.  Now I'll be using 1.4 pre-alpha.
>
> Can someone please point me to a good summary of the main changes made
> between these two versions?

See https://docs.djangoproject.com/en/dev/releases/1.3/ and
https://docs.djangoproject.com/en/dev/releases/1.4/.

Jacob

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

Re: Recommendations for load testing/profiling a django site server?

[Jacob Kaplan-Moss]

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

A few options I've used:

* Siege (http://www.joedog.org/index/siege-home) - fairly simple but
powerful HTTP load tester.

* JMeter (http://jakarta.apache.org/jmeter/) - much more complex (with
an ugly Java GUI), but can test multiple protocols, distribute load
testing across multiple machines, and has excellent reporting tools.

* Tsung (http://tsung.erlang-projects.org/) - can be used a lot like
Siege, but Tsung's real strength is that it's easy to extend (in
Erlang, for better or worse) for custom load testing tasks.

* Bees With Machine Guns
(http://blog.apps.chicagotribune.com/2010/07/08/bees-with-machine-guns/)
- OK, I'm mostly just mentioning this because it's got the Best Name
EVER. Useful to simulate traffic from multiple "directions" (uses
AWS).

Good luck!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 Knowledge Strorehouse

[Jacob Kaplan-Moss]

On Sat, Jul 9, 2011 at 8:01 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Hmm, some concerns:

Luckily, it's open source: https://github.com/django/djangoproject.com
-- patches welcome!

[If you want to add search to the community aggregator that'd make me
very happy; it's been on my todo list for ages...]

Jacob

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

Re: throttling login attempts to avoid brute force attacks

[Jacob Kaplan-Moss]

Hi folks --

Also see http://simonwillison.net/2009/Jan/7/ratelimitcache/ for a
discussion of a similar technique built on top of memcached.

Jacob

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

Re: 'module' object has no attribute 'Manipulator'

[Jacob Kaplan-Moss]

On Fri, Jun 24, 2011 at 3:00 PM, CareerDhaba tech  wrote:
> I am very new to Django just started working around with forms. I have been
> facing difficulty in getting a user registered. Anyways i was following
> steps given in James Bennet blog.
>
> http://www.b-list.org/weblog/2006/sep/02/django-tips-user-registration/

This is an incredibly old example, and it's written using Django's old
form system. I suggest you start with the official docs:

https://docs.djangoproject.com/en/1.3/topics/forms/

In general, the official docs are going to be better than most of what
you find randomly online, especially for basic stuff like "how do I
use forms?" Try to get familiar with the official docs and how to move
around and find things in 'em and I think you'll find most of what
you're looking for there.

Jacob

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

Re: Best practices to secure admin site

[Jacob Kaplan-Moss]

On Thu, Jun 23, 2011 at 3:33 PM, Phui-Hock  wrote:
> This question has been asked a few times, but is there a general set
> of best practices one should follow to secure Django admin site? A
> quick check on some of the Django powered websites leave /admin/ open
> to public access, and some don't even use https for login form
> submission.
>
> Although only users marked as staff are allowed to logging to admin
> site, but I am not quite comfortable to leave a "backend" site wide
> open and take chances. Or am I just being too paranoid?

There are no known vulnerabilities in the admin's auth code, but "no
known vulnerabilities" is a long way from "no vulnerabilities full
stop". I trust Django pretty far, but I don't think it's paranoia to
add a few other layers of security on top. I generally do the
following:

* Only allow HTTPS (to the admin, and perhaps to the entire site).
* Don't use "/admin/" -- I usually use a separate subdomain like
"backend.example.com", or sometimes just a different root (I often see
"nqzva" -- figuring out why is left as an exercise for the reader :).
* Limit access based on IP, when appropriate -- many corporate
settings will already have a VPN, for example, so piggyback on that if
possible.

Of the three, I consider SSL non-negotiable: there's no good reason to
allow insecure connections to the admin.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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.3 docs PDF

[Jacob Kaplan-Moss]

On Wed, Jun 1, 2011 at 4:47 PM, Oscar Carballal  wrote:
> I've just created a PDF (5.6MB, 1042 pages) with all the django 1.3
> docs [|], just in case someone need it (sometimes it's useful to have
> the docs offline).

Also see http://readthedocs.org/projects/django/, which has got links
to PDF downloads for 1.3, 1.2, and development trunk.

Jacob

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

Re: Specifying a database for a specific app

[Jacob Kaplan-Moss]

On Mon, May 30, 2011 at 10:00 AM, Philip Zeyliger  wrote:
> I have several installed applications within my Hue environment.  I'd like
> to use the multiple database support to route all database requests
> associated with apptwo.models into a database called "apptwo", while keeping
> everything else in the default database.  Is this possible?  It seems like
> I'd have to do quite a bit of work to write a custom router, whereas this
> seems like a pretty common case.

The database router is the right tool for this job (the only one, actually).

It might seem like "quite a bit of work," but it's actually very
simple. There's even an example in the docs
(https://docs.djangoproject.com/en/dev/topics/db/multi-db/#an-example)
that does almost exactly what you want. In a nutshell, something like
the following should do the trick::


def app_label(model):
"""Shortcut for getting a model's app_label"""
return model._meta.app_label

class AppTwoRouter(object):

def db_for_read(self, model, **hints):
if app_label(model) == 'apptwo':
return 'apptwo'
return None

db_for_write = db_for_read

def allow_relation(self, obj1, obj2, **hints):
if app_label(obj1) == app_label(obj2) == 'apptwo':
return True
return None

def allow_syncdb(self, db, model):
if db == 'apptwo':
return app_label(model) == 'apptwo'
elif app_label(model) == 'apptwo':
return False
return None

Jacob

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

Re: Is there an HTML editor that's Django-aware

[Jacob Kaplan-Moss]

On Monday, May 30, 2011, BobX  wrote:
> If anyone from the Django Project itself is listening then can I (very
> humbly) suggest that some editor recommendations would make a real
> fine addition to the info on the site (useful to n00b's like me
> anyway).

That's a good idea - thanks!

Where do you think such information should live? That is, at what
point in your process of learning Django would information about
editors have been helpful? Somewhere in the tutorial, or after?
Before?

Thanks,

Jacob

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

Re: Weird Error when following django book?

[Jacob Kaplan-Moss]

On Wed, May 25, 2011 at 1:04 PM, Boštjan Mejak  wrote:
> HTML source code can't be passed as a string. You morons.

This isn't OK. Stop it at once.

You've been warned about your tone once before. Please aim for a
professional, polite tone here or find another group to hang out in.
If you can't act nicely I will have to ban you, and I don't want to do
that.

Jacob

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

Re: forum and blog for developers

[Jacob Kaplan-Moss]

I think you're looking for http://www.djangoproject.com/community/.

Jacob

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

Re: Static files

[Jacob Kaplan-Moss]

Hi John --

Next time, can you please try to be a bit more polite? If you adopted
this sort of tone in person I'd write you off as a crazy person and
get away as quickly as possible. What makes you think it's acceptable
here?

Most people -- and I'm one -- have a severe allergy to answering
questions phrased with such hostility. You'd be amazed at how far a
polite tone goes. If you're rude, people aren't going to want to help
to.

Because I'm not a jerk, though, I will answer your question despite
your rudeness. You're probably either not using a RequestContext or
else you've left the staticfiles context processor out of
TEMPLATE_CONTEXT_PROCESSORS. You could be sure you're using a context
processor by using django.shortcuts.render(), or by passing a
context_instance argument to render_to_response. Alternatively, you
could use the get_static_url template tag.

I'd be happy to expand on the above and give you more details, but
only if you're willing to ask again -- politely, this time.

Thanks and good luck,

Jacob

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

Re: Pre fork or worker MPM

[Jacob Kaplan-Moss]

On Tue, May 17, 2011 at 6:00 PM, ydjango  wrote:
> I remembered reading this long back - "Django requires Apache 2.x and
> mod_python 3.x, and you should use Apache’s prefork MPM, as opposed to
> the worker MPM."

That statement dates back to when Django wasn't threadsafe (so we're
talking pre-1.0 here). These days Django's perfectly threadsafe
(though your may not be...) so worker isn't out of the question.

Jacob

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

Re: Pre fork or worker MPM

[Jacob Kaplan-Moss]

On Tue, May 17, 2011 at 4:15 PM, ydjango  wrote:
> I am using Python 2.5, django 1.1 with mod_wsgi 2.5
>
> Does it matter if I use prefork or worker MPM for apache?

In general, worker will use less RAM, thus allowing higher concurrency
and usually higher perceived performance.

But take that suggestion with a huge grain of salt: without knowing
specifics about your application the question is basically
unanswerable. worker's probably the right choice maybe 90% of the time
though.

> Which one is recommended for production use?

They're both fine for production.

Jacob

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

Re: REMOTE_USER authentication to 'Admin'?

[Jacob Kaplan-Moss]

On Tue, May 17, 2011 at 2:00 PM, Jeff Blaine  wrote:
> That gets us somewhere, because authenticating to Apache/LDAP as jblaine
> did NOT make a Django user jblaine.

That's interesting - perhaps LDAP is reporting a different username?
You could check in the auth_user table to see what's getting created
when you authenticate; you should see a entry get created the first
time you authenticate as a given user.

> Any clever ideas for where to shim some debugging code to see what is
> happening in the native Django stuff?

I'd start by subclassing RemoteUserBackend and throwing some logging
code into the configure_user (and perhaps clean_username) callbacks.
After that you could try subclassing RemoeUserMiddleware and again
adding some logging callbacks (in process_request, I think).

Jacob

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

Re: REMOTE_USER authentication to 'Admin'?

[Jacob Kaplan-Moss]

On Tue, May 17, 2011 at 1:31 PM, Jeff Blaine  wrote:
> Hi folks,
> I'm successfully using Apache with mod_authnz_ldap, WSGI, Django 1.3.  If I
> hit
> '/admin', I get asked to authenticate (BasicAuth done through LDAP).  I
> succeed.
> However, this just results in me then seeing the Django admin login screen
> instead
> of logging me in to Admin.
> What am I missing?

It's hard to be certain, but I'm fairly sure that you need to make
sure that the user in question (i.e. the one authenticated via
mod_authnz_ldap) has the "is_staff" flag set on the Django user
object.

Django requires that there be a User object in the database for each
user, so RemoteUserBackend creates missing User objects on demand (see
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py#L68
for the code). However, these automatically-created users won't have
any permissions or the "is_staff" flag set, so they won't be allowed
to log into the admin.

The solution is to subclass RemoteUserBackend and override the
"configure_user" method, setting permissions and staff/superuser flags
appropriately (perhaps via an LDAP query?) This is briefly mentioned
in the documentation (see
http://docs.djangoproject.com/en/dev/howto/auth-remote-user/#remoteuserbackend)
which has a few other details in case you need 'em.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 choose a license for an app or a project?

[Jacob Kaplan-Moss]

On Sun, May 15, 2011 at 9:58 PM, Kenneth Gonsalves
 wrote:
> go read the GPL and stop irritating everyone here.

Kenneth, that's uncalled-for -- please don't respond to rudeness with
more rudeness.

It's pretty clear to me that this discussion is incredibly off-topic
and that Bostjan has no interest in respecting our norms. Let's
respond by ignoring him, not stooping to his level.

Jacob

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

Re: Cache entire page *except* one block?

[Jacob Kaplan-Moss]

On Fri, May 13, 2011 at 3:01 PM, Nan  wrote:
> I'm working on a site where about 95% of the pages are "static" and
> change no more than once a week, and should therefore be cached;
> however, there are a couple blocks in the base template (login forms,
> blocks that load randomized content, etc) that shouldn't be cached.
> Is there any way to enable cache on everything else but disable it on
> those blocks?  I feel like it's extremely inefficient to have to hit
> the database for page data on every view of a static page because of
> that.
>
> I suppose that the static page query results could be cached, but a)
> they'd still have to be re-rendered, and b) that would mean updating
> every one of about 30 views, and any views built in the future, which
> doesn't feel very DRY or maintainable.  Am I missing something, or
> misunderstanding something fundamental about how Django's cache
> framework works?

The term you're looking for is "two-phase rendering": you basically
want to render the template once, cache that, and then later render
just a bit of it again.

Adrian wrote about the technique some time ago; see
http://www.holovaty.com/writing/django-two-phased-rendering/. There
are some tips there for building something by hand, or you could
django-phased, which seems to work out-of-the-box:
https://github.com/codysoyland/django-phased.

The technique I usually use is to use Varnish's ESI features
(http://varnish.projects.linpro.no/wiki/ESIfeatures) and push the
caching out to the edge. There's a writeup of a technique similar to
mine at http://yml-blog.blogspot.com/2010/01/esi-using-varnish-and-django.html,
and again there's an app that appears to provide the Django-y bits:
https://bitbucket.org/mlhamel/django-esi/src.

Good luck!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 choose a license for an app or a project?

[Jacob Kaplan-Moss]

On Fri, May 13, 2011 at 12:35 PM, Boštjan Mejak  wrote:
> Where to put my license? In a file or in all the modules? I'll use MIT
> license. Do I need to disclose the source code?

I'm sorry, but I have a policy of not answering questions that are
asked rudely, and you're being incredibly rude. If you stop trying to
hijack this thread, start a new one, and most importantly *ask
politely* I will try to help you out when I find some free time to do
so.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 choose a license for an app or a project?

[Jacob Kaplan-Moss]

On Fri, May 13, 2011 at 12:06 PM, Boštjan Mejak  wrote:
> This is getting way out of hand. I was hoping for a simple yes/no answer.
> And what I got? A bunch of yada yada.

This tone is uncalled for and borderline unacceptable here. You have
no right to demand anything from the people taking their free time to
help you here.

If you're unhappy with the free help you're getting I encourage you to
retain a lawyer. That's the only way you'll get definitive answers on
legal concerns.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 choose a license for an app or a project?

[Jacob Kaplan-Moss]

On Fri, May 13, 2011 at 11:30 AM, Thomas Weholt  wrote:
> Hmmm ... maybe, but because of the reusable app focus in django I
> think some sort of guideline regarding choice of license could be
> important.

The problem is that license choice is one of those "holy wars" that
geeks get into -- vi/emacs, mac/windows/linux, etc. etc. etc. Only
it's worse because you've got a bunch of laypeople trying to interpret
law, and we developers tend to fail rather spectacularly when trying
to interpret the law.

So any "official" advice anyone gave would just be a flashpoint for
flamewars, and I don't think anyone's brave enough to wade into this
particular problem. I'm certainly not.

I would like to make a few important points, though:

First, if you have a license you want (or need) to use: use it. Don't
let anyone tell you otherwise. It's *YOUR* software, and *YOU* get to
choose how to license it. I'd hope that you're making an educated
choice, but even if you're picking by throwing darts that's still your
prerogative.

That said, you do need to understand that licenses are more than just
legal terms of use. They're also important community signifiers. What
do I mean by "signifier"? Well, imagine you're in a meeting and
someone you don't know walks in wearing a suit. You'll have an
immediate first impression ("ah, here's a business guy") that'd differ
from seeing someone walk in wearing sandals and at-shirt ("hey, who's
the new developer?")

Well, licenses do that, too. A permissive, BSD-ish license sends a
message that's quite a bit different from the one sent by a
strong-copyleft GPL-ish license. It's hard to articulate just what
these messages are -- I have strong feelings on the matter so I can't
really talk dispassionately.

But I can point out that one of the most important aspects of this
message is one of membership and involvement. Again, think about the
meeting example: if you were going to attend a meeting with a bunch of
developers would you wear a suit? Maybe you would, but you'd probably
know they'd instantly peg you as an outsider. This could be useful --
if you're trying to buy a startup, you probably *want* to look
important and successful. But either way you probably know your
clothes send signifiers about how you see yourself in relation to the
community.

Again, licenses to that, too. In the Python and Django world,
permissive licenses are the norm. Python's licensed under a permissive
license (it's a weird one for historical purposes, but it's most like
the Apache license I think). Django's licensed under one of the most
permissive licenses available (the BSD license). Many Python projects,
and most Django apps, are BSD or MIT licensed. This means that putting
a GPL-licensed Django app is going to immediately stick out as
something a bit different.

I'm *NOT* saying that you should be choosing a license just to "fit
in"! Again, it's *YOUR* choice. The point I'm making is that the
social messages your license sends can be just as important as the
legal rights those license grant. In many cases, the social factors
can be more important than the legal ones.

Good luck, I hope I've not confused things even more for you!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 django admin log be trusted?

[Jacob Kaplan-Moss]

On Tue, May 10, 2011 at 4:59 PM, Paweł Roman  wrote:
> But does that mean that the django admin log is broken and cant be
> trusted? How come there isnt any trace of adding those items?

Well, I'd say "broken" might be a bit strong. Some cars drive 200 MPH,
but mine won't. Does that mean my car's "broken"? Of course not: it's
just not designed to drive that fast.

Similarly, the admin log isn't a designed to be a foolproof audit log.
It's a rough history trail, but entries in it are essentially advisory
and there are *plenty* of ways for content to be modified without
leaving an admin log entry.

Without seeing your code it's impossible to say exactly why these
events aren't in the admin log, but I'll try to make a guess or two.

If you take a look at the source, you can see that the admin log is
added by the `log_addition`, `log_change`, and `log_deletion` methods
on `ModelAdmin` (see
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L494).
These methods, in turn, are called by the admin views (`add_view`,
`change_view`, and `delete_view`) and also by the admin bulk delete
action (see 
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/actions.py#L46).

However, and this is key, these methods aren't called by anything
else. So actions won't be logged if you:

* Add, edit, or delete objects using any other mechanism than the
admin (e.g. your own views, directly from the Python shell, in the
database directly, etc.)
* Have a custom admin action that modifies objects and doesn't call a
log method.
* Have a custom admin view that doesn't call the super method or
manually call the log method.
* Use a custom admin site that overrides any of the log methods.
* And so on.

I'm willing to bet it's one of these things. But in any case, any code
path that modifies the database without calling a log method leaves
things out of the admin log.

My apologies if the documentation led you to believe that the admin
log was some sort of foolproof audit trail. It's anything but; if
there's money or legal issues on the table, you absolutely need
something more robust and harder to tamper with.

Jacob

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

Re: Loading initial data with a post_syncdb hook?

[Jacob Kaplan-Moss]

On Sun, May 8, 2011 at 4:25 PM, Adam Seering  wrote:
> I have some Python code that generates initial data for some of my tables; I
> currently call that code from a post_syncdb hook. In Django 1.3, it looks like
> Django now calls TRUNCATE (or an equivalent non-PostgreSQL-ism) on all tables
> after running syncdb and all of its post- hooks.

That... doesn't sound right. Here's all the SQL syncdb executes (for a
simple app with one table); notice the distinct lack of any TRUNCATE
statement.

Are you perhaps talking about doing this during testing? If so, you're
looking for unittest's setUp method:
http://docs.python.org/library/unittest.html#unittest.TestCase.setUp.

Jacob

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

Re: curl pages behind login_required

[Jacob Kaplan-Moss]

On Sun, May 8, 2011 at 3:17 PM, CarlFK  wrote:
> I am trying to curl pages that require being logged in via django's
> default auth.  I don't care if the actual login is done with curl,
> python, firefox or whatever is easiest.

Are you wedded to curl for the download? If it were me, I'd use
something like Mechanize (http://wwwsearch.sourceforge.net/mechanize/)
which can handle logging in, storing cookies, and doing the download.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 use jquery for point of Sale

[Jacob Kaplan-Moss]

On Fri, May 6, 2011 at 10:21 AM, Shawn Milochik  wrote:
> How to ask an actual question so maybe someone can answer it.

Shawn, that's uncalled-for. I'm super-impressed with how much work
you're putting into answer people's questions here, and I really do
appreciate it. But this sort of thing isn't a good tone to set around
here.

Yes, GKR's question was incredibly unclear and impossible to answer,
and yes this happens a lot around here. But we have to remember as
frustrating as these vague questions are to us, the person at the
other end is frustrated, too. Please be polite -- perhaps suggestions
about how to better word questions. Or just ignore it and move on. Far
better to say nothing than to say something mocking or hostile or
whatever.

GKR, you'll meet with much more success if you take the time to craft
a question with more details and information about what you're looking
for. Perhaps take the time to read
http://www.catb.org/~esr/faqs/smart-questions.html which goes into
some detail about how you can be successful asking for help on
technical mailing lists.

Again, thanks to everyone who takes time to answer questions. But
please try to be polite and kind. Keep the tone here something we can
all be proud of.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 use jquery for point of Sale

[Jacob Kaplan-Moss]

On Fri, May 6, 2011 at 10:21 AM, Shawn Milochik  wrote:
> How to ask an actual question so maybe someone can answer it.

Shawn, that's uncalled-for. I'm super-impressed with how much work
you're putting into answer people's questions here, and I really do
appreciate it. But this sort of thing isn't a good tone to set around
here.

Yes, GKR's question was incredibly unclear and impossible to answer,
and yes this happens a lot around here. But we have to remember as
frustrating as these vague questions are to us, the person at the
other end is frustrated, too. Please be polite -- perhaps suggestions
about how to better word questions. Or just ignore it and move on. Far
better to say nothing than to say something mocking or hostile or
whatever.

Again, thanks to you -- and everyone! -- who takes time to answer
questions. But please try to be polite and kind. Keep the tone here
something we can all be proud of.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 draw line charts in Django?

[Jacob Kaplan-Moss]

On Thu, May 5, 2011 at 5:05 AM, Nge  wrote:
> I already created a view and can extract data from database.But I have
> a problem. I don't know how to send to template and how to create js/
> ajax. Can you share me sample?

I've recently done a project that uses Ajax, jQuery, and Flot to do
some charting/graphing. It's not incredibly well-commented, but take a
look and see if it helps:
https://github.com/jacobian/django-dev-dashboard

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 group_by difficulties

[Jacob Kaplan-Moss]

On Wed, May 4, 2011 at 9:23 AM, Satan Study Django
 wrote:
> I can also use the direct sql query in the code. But on cellular it
> level does not seem right -)

Well, if it were me, I'd just use the raw SQL. I'd guess that about 5
to 10% of the time I find that my queries are better expressed in SQL
than in Python. I see nothing wrong with dropping down to raw SQL
where it's easier and clearer. Why make extra work for youself?

Jacob

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

Re: Stuck at integration step w/ WSGI

[Jacob Kaplan-Moss]

On Tue, May 3, 2011 at 5:07 PM, Jeff Blaine  wrote:
> Thanks Jacob -- does the site entry in the database have to be anything
> specific?  We don't really use that.  Just put any old thing in there via
> Admin in the development server?

Well, if you want all the parts of the admin to work correctly
(especially those "view on site" buttons and similar features) you
probably should set the entry to something that actually exists.
Django will happily think your site is running on
http://www.example.com/, but I really doubt that it is.

> I have a SITE_ID = 1 in settings.py from, I assume, when the project was
> made.  I suspect when I deleted the 'example.com' site last week, that broke
> the relationship, no?

Probably, yes.

When Django needs to know which site it's running on it does something like::

Site.objects.get(id=settings.SITE_ID)

If you've broken that (by deleting the site object, changing SITE_ID,
taking django.contrib.sites out of INSTALLED_APPS, etc.) then it won't
quite work, as you might imagine.

Jacob

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

Re: Stuck at integration step w/ WSGI

[Jacob Kaplan-Moss]

Hi Jeff --

To make the admin work w/r/t sites, you'll need three things:

* An entry in the sites table.
* A setting SITE_ID set to the ID of the Site entry you'd like to use
(i.e. SITE_ID = 1).
* `django.contrib.sites` in your INSTALLED_APPS.

Check all three; I'll be you're missing one or two of them.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 Admin template

[Jacob Kaplan-Moss]

On Tue, May 3, 2011 at 1:23 PM, Rich  wrote:
> I know it's possible to overwrite the Django admin templates by
> copying the templates to your local project.  I want to modify the
> "add user" template but cannot seem to figure out which template it
> is.  I want to create a button which will use APG to generate a random
> password rather than typing in the password.  Anyone, have any idea
> how this can be accomplished.

You should check out the docs:
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#overriding-admin-templates.
That bit walks you through the process, which is basically creating an
"admin///.html" template with the app-specific
template you'd like. The docs list each template that can be
overridden; the one you want is "change_form.html". So since you're
working on the "user" model in the "auth" app you'd create a template
named "admin/auth/user/change_form.html".

Hope that helps,

Jacob

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

Re: .save() works with no (custom, not 'id') primary key specified?

[Jacob Kaplan-Moss]

On Fri, Apr 29, 2011 at 12:17 PM, Jeff Blaine  wrote:
> "primary_key=True implies null=False and unique=True. Only one primary key
> is allowed on an object."
> So that unique=True part is inaccurate?  Or is that, again, another thing
> that will fail only at validation?

Maybe this'll help::

# Log every SQL query
>>> import logging
>>> l = logging.getLogger('django.db.backends')
>>> l.setLevel(logging.DEBUG)
>>> l.addHandler(logging.StreamHandler())

# Now let's play...
>>> from myapp.models import Device
>>> d1 = Device()
>>> d1.save()
(0.002) SELECT (1) AS "a" FROM "cfpk_device" WHERE
"cfpk_device"."propertyno" = E''  LIMIT 1; args=('',)
(0.001) INSERT INTO "cfpk_device" ("propertyno") VALUES (E''); args=('',)

>>> d2 = Device()
>>> d2.save()
(0.001) SELECT (1) AS "a" FROM "cfpk_device" WHERE
"cfpk_device"."propertyno" = E''  LIMIT 1; args=('',)

You have to remember that `object.save()` could mean INSERT *or*
UPDATE depending on whether the object with the given primary key
exists or not. When you create a new device, because again the default
is the empty string, you've already got one of those in the DB. Django
notices that it doesn't need updating, and so it doesn't update it.

Now consider this:

>>> d2.save()
(0.001) INSERT INTO "cfpk_device" ("propertyno") VALUES (E''); args=('',)
Traceback (most recent call last):
...
IntegrityError: duplicate key value violates unique constraint
"cfpk_device_pkey"
DETAIL:  Key (propertyno)=() already exists.

If you force an insert, you'll see the error you're expecting.

I'm sorry if you think it's broken. I disagree, though: Django's
working the way we designed it to work. You've exposed a subtle
edge-case (which shows just one reason why I use surrogate keys almost
without exception).

Jacob

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

Re: .save() works with no (custom, not 'id') primary key specified?

[Jacob Kaplan-Moss]

On Fri, Apr 29, 2011 at 11:47 AM, Jeff Blaine  wrote:
> How is this possible based on the model below?
> d = Device()
> d.save()
> # no errors
> class Device(models.Model):
>     propertyno      = models.CharField('Property Number',
>                                        max_length=10,
>                                        primary_key=True)

It's because CharField have a `default` of "" -- that is, the empty
string. So you've created a Device with a propertyno of "" (again, an
empty string). That's a valid pk value as far as some DBs are
concerned.

Notice that the model won't validate -- because you haven't set
`blank` to `True` -- but it will save. (For backwards-compatibility
reasons, save() can't trigger validation).

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 question about lookups that span relationships

[Jacob Kaplan-Moss]

On Fri, Apr 22, 2011 at 5:36 AM, Michael Radziej  wrote:
> In SQL, it's something along
>
> SELECT ... FROM blog
> JOIN entry e1 on e1.entry_id = blog.id
>     AND e1.pub_date <= ...
>     AND e1.headline LIKE "%Easter%"
>     AND NOT exists
>     ( SELECT id from entry e2
>       WHERE e2.entry_id = blog.id
>       AND e2.pub_date <= ...
>       AND e2.pub_date > e1.pub_date
>     )
>
> Well ... even after 5 years with Django, I still think more in SQL than
> in Django ORM. Does anyone know how to that in the ORM?

Blog.objects.raw('''SELECT * FROM blog
JOIN entry e1 on e1.entry_id = blog.id
AND e1.pub_date <= ...
AND e1.headline LIKE "%Easter%"
AND NOT exists
( SELECT id from entry e2
  WHERE e2.entry_id = blog.id
  AND e2.pub_date <= %s
  AND e2.pub_date > e1.pub_date
)''', [pub_date])

...

No, really -- if I was faced with a query, like this, that was easier
to express with SQL, I'd reach for `raw()` long before trying to
figure if I could twist the ORM to do my bidding.

Jacob

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

Re: website path

[Jacob Kaplan-Moss]

2011/4/20 Ján Vorčák :
>    PythonHandler django.core.handlers.modpython

You really, really, really should upgrade to mod_wsgi. mod_python is a
dead project, and support for it be removed  from Django in the
future. More importantly, you're not going to find a whole lot of
people who can help you out with mod_python. That is, I've seen this
problem before, but it's been so long since I've switched away that I
can't recall what the solution is.

If you absolutely can't switch, read
http://docs.djangoproject.com/en/dev/howto/deployment/modpython/#basic-configuration
very carefully, especially the parts about `django.root`. My guess is
that you've got something slightly wrong there, though what you've
posted looks correct to me.

Good luck,

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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

[Jacob Kaplan-Moss]

2011/4/19 Juan Pablo Romero Méndez :
> 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

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

Re: website path

[Jacob Kaplan-Moss]

2011/4/19 Ján Vorčák :
> I've installed a django on my server (running on apache), but I've
> configured it to run using url like
> www.mydomain.com/django-application/
>
> Now when I access some url from django using absolute url it
> automatically redirects me to
> www.mydomain.com/someapplication
> instead of
> www.mydomain.com/django-application/someapplication

This sounds like a problem I've seen when using Django under
mod_python -- are you using mod_python?

Either way, can you share your Apache config and the relevent
URLconfs? It's hard to figure out what's wrong without all the
details.

Jacob

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

Re: db routing by request

[Jacob Kaplan-Moss]

On Tue, Apr 19, 2011 at 5:06 AM, Michael P. Soulier
 wrote:
> I noticed that the request object is not passed to the database router, the
> intention seems to mainly be to route by model. I have a case where I want to
> route based on session data in the request. While I know that I can
> explicitely use the using() method, this will be a tad labourious. Will it be
> possible in the future to pass the request object to the database router?

Probably not -- that'd be a pretty heinous violation of separation of
concerns. Remember that Django can (and often is) used outside of a
web request/response cycle (think management commands, cron jobs,
interactive shells, ...).

The right way is indeed to use `using()` and leave session-specific
handling where it belongs, in the views.

[If you insist on making it automagical, you could stuff the request
object in a threadlocal. That wouldn't pass *my* code review, but
luckily you don't work for me :)]

Jacob

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

Re: Cannot submit tickets - always marked as spam!

[Jacob Kaplan-Moss]

Hi Jeff --

It's not you; we get a *lot* of spam, and so our spam filters are
overly aggressive.

You can get around 'em if you create an account. Just visit
http://www.djangoproject.com/accounts/register/, register, and then
log into Trac once you have the account set up.

Thanks, and sorry about the false positive!

Jacob

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

Re: get_object_or_404 Tutorial part 3

[Jacob Kaplan-Moss]

On Wed, Apr 13, 2011 at 6:41 AM, Yuka Poppe  wrote:
> I noticed this myself a while back; It was'nt django specific, and I dont
> know about IE, I generally try to avoid using that; But in case of Chrome,
> whenever it encounters a 404 error (or certain other conditions) it seems to
> decide the visitor is better off being served a generic google
> designed/generated status report about whats happening on the page then one
> authored by the webserver/webapp itself.

It actually has to do with the length (in bytes) of the 404 page.
Certain browsers -- some versions of IE, and Chrome -- detect "short"
404 pages and substitute the browser's 404 page instead.

I believe that the cutoff is 512 bytes, but you may want to test in
different browsers to be sure.

To fix it, you'll just have to pad your 404 page; this is why you'll
sometimes see something like::



In the source for 404 pages.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 find it in your hearts to expose filter_or_exclude at a global level.

[Jacob Kaplan-Moss]

On Mon, Apr 11, 2011 at 11:23 AM, sh...@bogomip.com  wrote:
> IMHO (which is very H) _filter_or_exclude should be public.  I can't
> find a compelling reason for it not to be other than it has never
> been.

Just go ahead and use it if you find it useful! The Python philosophy
is that we're all "consenting adults", so there's nothing preventing
you from using a so-called-private function if you find it useful. As
long as you're aware that you're using an API prone to change between
versions you'll be just fine. Test those parts of your code carefully
when you upgrade Django and you won't get bitten if it changes.

Jacob

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

Re: Best Practice for Raw SQL

[Jacob Kaplan-Moss]

On Mon, Apr 11, 2011 at 7:53 AM, Dan Gentry  wrote:
> Where I run into trouble is that the query returns data in columns,
> but not objects. That means that I can’t reference an object attribute
> using dot notation in my templates or views. Instead, I have to
> include each attribute that will be needed as a query column. This
> will limit what I or someone else can do in templates later without a
> mod to the query.

You're looking for the `raw()` method: http://django.me/raw. It takes
a raw SQL query and yields models for you.

Jacob

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

Re: Cascade delete not entirely correct in 1.3?

[Jacob Kaplan-Moss]

On Wed, Apr 6, 2011 at 2:41 PM, Aaron Madison  wrote:
> I'm not sure if attaching files straight through email will work or not...

I meant on the ticket. django-users is so high traffic that it's
likely that developers could miss stuff posted here, so giving all the
information needed on the ticket is useful. I took the liberty of
posting your traceback there; thanks!

Jacob

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

Re: Cascade delete not entirely correct in 1.3?

[Jacob Kaplan-Moss]

On Wed, Apr 6, 2011 at 11:14 AM, amadison  wrote:
> It you run the test case against django 1.3 it blows up... in django
> 1.2.5 it passes.

Just a quick process point: it helps a lot if you post the actual
error you're seeing, traceback and all.

Unless Django's literally blowing up your computer, in which case I
suggest you stop buying the TNT-powered hard drives.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 manager and request

[Jacob Kaplan-Moss]

On Wed, Mar 30, 2011 at 1:11 PM, Tony  wrote:
> Is there a way to use the "request.user" attributes in a custom model
> manager?  So I could filter by certain attributes the current logged
> in user has?  This is the preferable way I would like to filter the
> objects the user sees, so if there is a way, I would appreciate the
> help.  If there is no way to do it like this, I would be open to other
> suggestions although, the way my project is structured I dont want to
> do this in my view functions.

First, you need to understand that doing it in the view function is
the right place to do it. There it's easy; you'd just do something
like::

def my_view(request):
objects = MyModel.objects.viewable_by(request.user)

Your question is a bit like asking, "Is there a good way to get more
ventilation in this room? I know I could just open a window, but the
way the room is structured I'd rather cut holes in the wall or
something." That is, avoiding doing view-like things in views is
deliberately doing things the hard way.

So please, think about doing this right. The guy who has to maintain
your code will thank you.

That said, if you *must* go about this the wrong way, the typical
approach is to combine a piece of middleware (hack alert #1) with
threadlocals (hack alert #2). The middleware would look something
like::

# myapp/middleware.py

import threading

evil_threadlocals = threading.local()

def get_request():
return evil_threadlocals.request

class EvilMiddleware(object):
def process_request(self, request):
evil_threadlocals.request = request

You'd then add ``myapp.EvilMiddleware`` to ``MIDDLEWARE_CLASSES``, and
then deep in your manager you'd do::


class MyManager(models.Manager):
def evil_hacky_method(self):
from myapp.middleware import get_request
return self.filter(user=get_request())

Hopefully I've made it clear that doing this is a bad idea, so
*please* think about a light refactor before you head down this path.

Jacob

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

Re: Admin broken with large data table

[Jacob Kaplan-Moss]

On Tue, Mar 29, 2011 at 5:56 AM, Malcolm Box  wrote:
> On one of my models, the admin choice_list page is taking minutes to
> load, which makes it somewhat broken.
>
> The table has about 2M rows and about 2.6GB in size, on InnoDB/MySQL.
> As far as I can tell, what's breaking things is the paginator code
> that is doing a SELECT COUNT(*) which is known to be glacially slow on
> InnoDB with certain types of table.

Yup, this is a known problem: pagination in the admin isn't efficient
and breaks down past a certain point.

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

In 1.3 you should be able to override ModelAdmin.get_paginator
(http://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_paginator).
You'll have to subclass django.core.paginator.Paginator and provide an
interface that doesn't perform COUNTs.

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

Jacob

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

Re: Updating to Django 1.3 - how to preserve file field previous behaviour

[Jacob Kaplan-Moss]

On Sun, Mar 27, 2011 at 6:47 PM, Russell Keith-Magee
 wrote:
> As was suggested when you raised this on django-dev, if you want the
> old behavior, write a subclass of FileField that reintroduces the old
> behavior.

... and for those who're not reading over there, here's some code you
might try: https://gist.github.com/889692. Make sure to read the
WARNING before you put that in production...

Jacob

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

Re: Read-only fields and complex relationships in admin

[Jacob Kaplan-Moss]

On Fri, Mar 25, 2011 at 6:39 PM, Micah Carrick  wrote:
> I have an application which handles a typical "checkout" process for an
> e-commerce website. Orders from online customers end up in several models
[... snip complex problem ...]

> Anybody have any tips, links to articles, etc. that
> might help me research the best approach for this project?

Yes: don't use the admin for this.

Really, I know it's tempting because the admin gives you like 50% of
what you want for free. But trust me when I tell you that if you go
down the path of trying to kludge the admin into supporting your
custom workflow you will be very unhappy. You'll get to 90% very
quickly, and then you'll spend a ridiculous amount of time trying to
close the final gap. You never quite will, and your app won't "feel"
right. Sooner or later you'll give up and write custom views from
scratch, throwing away all that hard work.

Really: I've seen this happen more times than I can count. Don't go
down this path.

Just write custom views. Try out some apps that reproduce certain
admin features -- apps like django-tables
(https://github.com/miracle2k/django-tables), django-filter
(https://github.com/alex/django-filter), django-pagination
(https://github.com/ericflo/django-pagination), and
django.contrib.formwizard or perhaps django-formwizard
(https://github.com/stephrdev/django-formwizard). They might save you
a bit of time, but you'll save the most time by not trying to force
the admin into doing something it's not good at.

Jacob

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

Re: unique_for_date not working?

[Jacob Kaplan-Moss]

Hi Ryan --

On Fri, Mar 25, 2011 at 3:55 AM, Ryan Osborn  wrote:
> I am using django 1.3 and have the following in my models.py:
>
> class Entry(models.Model):
>    title = models.CharField(max_length=255)
>    slug = models.SlugField(unique_for_date='created')
>    created = models.DateField(auto_now_add=True, editable=False)
>
> However, I can add an entry in the admin interface with a slug and
> then immediately afterwards add another entry with the same slug
> without an error being rasied.  Am I missing something?

Basically what's happening is that `auto_now_add` and `editable`
outdated kludges. Both work by actually excluding the field in
question from the admin form, which means it's not available for
validation so none is ran.

A better approach, I think, would be to use something like::

import datetime
from django.db import models

class Entry(models.Model):
   title = models.CharField(max_length=255)
   slug = models.SlugField(unique_for_date='created')
   created = models.DateField(default=datetime.date.today)

This will work as expected in the admin and in model forms.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 select tables in inspectdb?

[Jacob Kaplan-Moss]

On Thu, Mar 24, 2011 at 3:07 PM, Savio Sabino  wrote:
> How I select what tables (in a db with 900 tables) has the model
> generated for inpectdb?

Sorry, but you can't: you'll need to run inspectdb and then edit the
generated code by hand to edit out the models you don't want.

Jacob

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

Re: Override table name(s) in application deployment

[Jacob Kaplan-Moss]

On Thu, Mar 24, 2011 at 12:30 PM, Flo Ledermann
 wrote:
> I was quite surprised that I couldn't find a way to override table
> names for an application's models on a per-deployment basis (i.e. in
> settings.py or some other project/site specific file instead of
> modifying the models.py file of the app itself)

Yup, I've missed this feature quite a few times myself. I'd love to
see a good solution. Of course, it's a bit like If You Give a Mouse a
Cookie here: once you start customizing table names on a
per-deployment basis now you're going to want to customize column
names. And once you do that you'll want to customize indexes. And
then...

But yes, I'd be thrilled to see a proposal here. Double bonus points
if it doesn't introduce a new setting :) Perhaps this might become a
feature of the DB router?

Jacob

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

Re: Custom admin interface

[Jacob Kaplan-Moss]

Hi Tsolmon --

You can find documentation on Django's admin interface at
http://docs.djangoproject.com/en/1.3/ref/contrib/admin/. It should
tell you enough to get started.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 install psycopg2 using Pip?

[Jacob Kaplan-Moss]

Hi Andre --

This indicates that you don't have the development packages for
PostgreSQL. psycopg2 is written mostly in C, and needs to be compiled
and linked against PostgreSQL. It does this by running a command
called pg_config, which is part of the PostgreSQL dev package.

You haven't indicated which platform you're on, so I can't tell you
exactly how to install the dev packages. On Ubuntu, it'd be "apt-get
install libpq-dev", for example.

Since this isn't really Django-related, you might want to also take a
look at the psycopg2 docs, especially the parts about building
problems: 
http://www.initd.org/psycopg/docs/faq.html#problems-compiling-and-deploying-psycopg2.

Good luck,

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send 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 multiple databases router

[Jacob Kaplan-Moss]

Howdy --

On Tue, Mar 22, 2011 at 5:17 AM, dy  wrote:
> # model in app test2,store to test2
> class Test2(models.Model):
>    name = models.CharField(max_length=30,verbose_name="test2")
>    test1 =
> models.ForeignKey('test1.Test1',verbose_name="FK_test1",blank=True,null=True)

Just to be sure I'm reading this right: you want this field to be a
foreign key from Test2, stored on the "test2" database, to the Test1
model stored on the "default" database?

If so, this simply isn't supported by Django. You can't have foreign
keys between tables on two different databases. If you think about
about the underlying database and what a foreign key reference really
is that should make sense.

There's a few workarounds (like an IntegerField and some manual
tracking of related IDs), but Django doesn't support this. I'm sorry
that it worked at all in the first place; it never should have.

Jacob

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

Re: ANN: Server upgrade on djangoproject.com

[Jacob Kaplan-Moss]

On Mon, Jan 31, 2011 at 2:40 AM, Shawn Milochik  wrote:
> I'm seeing the code samples being cut off in the docs as well.
> http://docs.djangoproject.com/en/dev/topics/signals/
> See sample under:
> Preventing duplicate signals

It's working for me (Chrome/Safari OSX), so it's probably a
browser-specific thing. Can you tell me which browser your using on
what platform, and give it a try with a different browser or two just
to make sure?

Thanks,

Jacob

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

Re: ANN: Server upgrade on djangoproject.com

[Jacob Kaplan-Moss]

On Fri, Jan 28, 2011 at 3:33 PM, Jacob Kaplan-Moss  wrote:
> I'm starting the switchover to the new djangoproject.com server right
> now. Might be around 5 mins of downtime or so.

Migration should be complete now. I'm still cleaning up a few
last-minute things, but if you notice anything wrong please pop into
#django-dev on freenode and let me know.

Jacob

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

ANN: Server upgrade on djangoproject.com

[Jacob Kaplan-Moss]

Hi folks --

I'm starting the switchover to the new djangoproject.com server right
now. Might be around 5 mins of downtime or so.

Jacob

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

Call for proposals -- PyCon 2011

[Jacob Kaplan-Moss]

Call for proposals -- PyCon 2011 -- 
===

Proposal Due date: November 1st, 2010

PyCon is back! With a rocking new website, a great location and
more Python hackers and luminaries under one roof than you could
possibly shake a stick at. We've also added an "Extreme" talk
track this year - no introduction, no fluff - only the pure
technical meat!

PyCon 2011 will be held March 9th through the 17th, 2011 in Atlanta,
Georgia. (Home of some of the best southern food you can possibly
find on Earth!) The PyCon conference days will be March 11-13,
preceded by two tutorial days (March 9-10), and followed by four
days of development sprints (March 14-17).

PyCon 2011 is looking for proposals for the formal presentation
tracks (this includes "extreme talks"). A request for proposals for
poster sessions and tutorials will come separately.

Want to showcase your skills as a Python Hacker? Want to have
hundreds of people see your talk on the subject of your choice? Have
some hot button issue you think the community needs to address, or have
some package, code or project you simply love talking about? Want to
launch your master plan to take over the world with Python?

PyCon is your platform for getting the word out and teaching something
new to hundreds of people, face to face.

In the past, PyCon has had a broad range of presentations, from reports
on academic and commercial projects, tutorials on a broad range of
subjects, and case studies. All conference speakers are volunteers and
come from a myriad of backgrounds: some are new speakers, some have been
speaking for years. Everyone is welcome, so bring your passion and your
code! We've had some incredible past PyCons, and we're looking to you to
help us top them!

Online proposal submission is open now! Proposals  will be accepted
through November 10th, with acceptance notifications coming out by
January 20th. To get started, please see:

   

For videos of talks from previous years - check out:

   

For more information on "Extreme Talks" see:

   

We look forward to seeing you in Atlanta!

Please also note - registration for PyCon 2011 will also be capped at a
maximum of 1,500 delegates, including speakers. When registration opens
(soon), you're going to want to make sure you register early! Speakers
with accepted talks will have a guaranteed slot.

Important Dates:
   * November 1st, 2010: Talk proposals due.
   * December 15th, 2010: Acceptance emails sent.
   * January 19th, 2010: Early bird registration closes.
   * March 9-10th, 2011: Tutorial days at PyCon.
   * March 11-13th, 2011: PyCon main conference.
   * March 14-17th, 2011: PyCon sprints days.

Contact Emails:
   Van Lindberg (Conference Chair) - v...@python.org
   Jesse Noller (Co-Chair) - jnol...@python.org
   PyCon Organizers list: pycon-organiz...@python.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-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: Setting initial data for an M2M field

[Jacob Kaplan-Moss]

On Tue, Feb 16, 2010 at 10:01 AM, Tom  wrote:
> I can set other initial data, for example to the 'notes' CharField
> fine.  I guess my question boils down to: how do you set initial data
> for a many-to-many field?

The initial data for a many to many field needs to be a list. So::

f = EmailForm(initial={'contacts': [contact.id]})

Remember: it's a *many-to-many* field, which means that the field has
*many* values.

Also notice the error message: "'long' object is not iterable". This
is telling you that someone, somewhere, has tried to iterate (treat as
a list) something (a long integer) that isn't a list object.

Jacob

-- 
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: regex infinite loop with 100% cpu use in django.forms.fields.email_re - DOS hole?

[Jacob Kaplan-Moss]

Just as an update for anyone following this thread:

This was indeed a security exploit, and it has been fixed. See
http://www.djangoproject.com/weblog/2009/oct/09/security/ for details.

Jacob

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

Re: ImageFile bug? (Re: ImageField questions)

[Jacob Kaplan-Moss]

On Sun, Jul 26, 2009 at 11:10 PM, Rusty Greer wrote:
> i applied the patch you mentioned before (to my 1.0.2 release):

Yeah, the fix is predicated on some file storage refactoring that's
too intensive to reach the 1.0.X series. You'll need to upgrade to 1.1
to get the fix.

Jacob

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

Re: ImageFile bug? (Re: ImageField questions)

[Jacob Kaplan-Moss]

2009/7/24 Rusty Greer :
> that bug actually doesn't fix my case.  if i alter the patch to just
> do a file.close() in all cases, it works.  is there another patch to
> close the file opened outside of this class?

I'm not sure I follow; let me make sure I understand you:

* You've verified that you're still having problems when running under
Django 1.1 RC 1?

* If you're opening the image file yourself, you need to make sure you
also close it. Django can't "guess" whether you want to leave the
image open or not, so you'll need to make sure any files you open are
closed.

Jacob

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