Re: Ad-hoc Django integration for fault-tolerance

[Russell Keith-Magee]

For those wondering -- I've found out the cause. Google stopped
sending notifications about messages to django-dev awaiting
moderation, so there was a backlog of messages that needed to be
moderated. Karen Tracey discovered the backlog this morning, and
approved the messages; hence the flood.

Yours,
Russ Magee %-)

On Sat, Jan 28, 2012 at 12:31 PM, Adam "Cezar" Jenkins
 wrote:
> I also got the backlog, in addition my gmail has been buggy and slow for a
> few days, so I'm assuming it's Google having an issue.
>
> On Fri, Jan 27, 2012 at 8:18 PM, Russell Keith-Magee
>  wrote:
>>
>> On Sat, Jan 28, 2012 at 3:47 AM, Alec Taylor 
>> wrote:
>> > Thanks, hadn't thought to go with NoSQL. :)
>> >
>> > Quick side-note: I received 14 emails on the django-devel list between
>> > 30 and 40 minutes ago. Strange, seeing as this one is dated 10 days
>> > ago. Google Groups problem?
>>
>> You're not the only one who got this backlog -- I got it too. I'm have
>> no ideas about the underlying cause.
>>
>> Yours,
>> Russ Magee %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

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

Re: Ad-hoc Django integration for fault-tolerance

[Adam "Cezar" Jenkins]

I also got the backlog, in addition my gmail has been buggy and slow for a
few days, so I'm assuming it's Google having an issue.

On Fri, Jan 27, 2012 at 8:18 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Sat, Jan 28, 2012 at 3:47 AM, Alec Taylor 
> wrote:
> > Thanks, hadn't thought to go with NoSQL. :)
> >
> > Quick side-note: I received 14 emails on the django-devel list between
> > 30 and 40 minutes ago. Strange, seeing as this one is dated 10 days
> > ago. Google Groups problem?
>
> You're not the only one who got this backlog -- I got it too. I'm have
> no ideas about the underlying cause.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Feature request: read-only admin view

[Russell Keith-Magee]

On Sat, Jan 21, 2012 at 1:02 AM, Chris Wilson  wrote:
> Hi all,
>
> I really like how the admin interface does a lot of the work for me in
> developing a site with basic CRUD functions, and a few free bonuses
> like pagination and list filtering.
>
> I agree with all the comments on #820  ticket/820> requesting this feature (as well as the "view" permission
> which goes with it).
>
> This ticket and several others were closed because a design decision
> has been made that the admin interface is for admins only, and such a
> feature is out of scope. A lot of people believe that it should be in
> scope. Therefore I would like to politely request a reconsideration of
> this decision.

Even though I'm the person who wonfixed the ticket most recently, I'm
inclined to agree with you -- but for a different reason.

The original reason -- that the admin isn't intended as a general
purpose site, just a backend editing interface -- is still valid. I'm
not in favor of trying to turn the admin into something that people
will try to interpret as a publicly visible CMS.

However, over time, we've added a complication. We now have object
level permissions, so it's possible for an admin user to see a list of
objects, of which only *some* are editable. To me, the logical
extension of this feature is that you should be able to view some
objects in the admin, and edit others.

So, count this as a tentative +0 for the idea, qualified by the fact
that it in no way represents a promise to help this patch into trunk.
I've got 99 problems, but view permissions in the admin ain't one. :-)

I'd also point out that at DjangoCon.US last year, there were some
initial discussions about developing a "NewAdmin". I don't think this
effort has gone very far since then, but it's worth noting that there
is high-level agreement that Django's admin is in need of a bit of a
shakeup; increased functionality (like view permissions) might be
something that could fit into that broader change.

Yours,
Russ Magee %-)

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

Re: Ad-hoc Django integration for fault-tolerance

[Russell Keith-Magee]

On Sat, Jan 28, 2012 at 3:47 AM, Alec Taylor  wrote:
> Thanks, hadn't thought to go with NoSQL. :)
>
> Quick side-note: I received 14 emails on the django-devel list between
> 30 and 40 minutes ago. Strange, seeing as this one is dated 10 days
> ago. Google Groups problem?

You're not the only one who got this backlog -- I got it too. I'm have
no ideas about the underlying cause.

Yours,
Russ Magee %-)

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

Re: MySQL connection pooling - preferred method??

[Russell Keith-Magee]

Hi Cal,

I'm not exactly sure what it is you're looking for.

The position of the core team has been fairly clear -- there are third
party connection pooling tools that handle connection pooling very
well.

The recommendation of the core team is that you should use these tools.

The alternative is to try an engineer a solution into Django's DB
connection stack. This solution would inevitably be less stable than
one that originates from a project whose sole purpose is implementing
a connection pool.

If you're looking for a recommendation for a connection pooler for
MySQL, that's another matter. Unfortunately, I can't be much help
here; I don't keep on top of developments in the MySQL world, so I
can't comment with any authority.

Yours,
Russ Magee %-)

On Thu, Jan 26, 2012 at 5:01 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Damn - no thoughts on this from anyone?
>
>
> On Wed, Jan 25, 2012 at 12:11 AM, Cal Leeming [Simplicity Media Ltd]
>  wrote:
>>
>> Hi all,
>>
>> After spending about 30 minutes looking through old tickets, long
>> discussion threads and various blogs, I'm still not clear on the MySQL
>> connection pooling topic.
>>
>> To quote Russ: "the capability already exists in third party tools, and
>> they're in a position to do a much better job at it than us because it's
>> their sole focus" [3]
>>
>> Could a core dev (or anyone else with experience on this) clarify which
>> approach is recommended, on the following conditions:
>>
>> * Safety (should not cause any strangeness with query cache or ORM)
>> * Performance (should avoid causing Django to open a new database
>> connection on every request)
>>
>> I found various ways to accomplish this, one of which was to use
>> SQLalchemy[1], another was to stop Django from closing the database
>> connection after each query[2].
>>
>> I'm hoping this thread will also serve as a final answer for anyone else
>> looking for clarification.
>>
>> Many thanks
>>
>> Cal
>>
>>
>> [1] http://menendez.com/blog/mysql-connection-pooling-django-and-sqlalchemy/
>>
>> [2] http://stackoverflow.com/questions/1125504/django-persistent-database-connection
>>
>> [3] http://groups.google.com/group/django-developers/browse_thread/thread/6f1e9c6e81aff1de/bf34e546e4217277?lnk=gst&q=mysql+pooling#bf34e546e4217277
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

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

Re: Where should this test be placed

[Russell Keith-Magee]

On Fri, Jan 20, 2012 at 7:14 AM, Aaron Cannon
 wrote:
> Hi all.
>
> Trying to help out with some of the Trac tickets, and wasn't sure
> where tests should be placed for this ticket:
>
> https://code.djangoproject.com/ticket/17504
>
> Is there an existing package that it would make sense to use for
> testing this particular bit of functionality?

Hi Aaron,

Apologies for taking so long to get back to you.

In this case, you're testing specific behavior of the auth module, so
the tests should be in django.contrib.auth.tests; from a quick poke
around, the basic module is probably where you need to put them.

Yours,
Russ Magee %-)

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

Re: Regarding queries cache...

[Russell Keith-Magee]

On Sat, Jan 14, 2012 at 1:51 PM, "Germán M. Bravo"  wrote:
> Regarding queries cache... but not in the way almost everyone usually thinks 
> of this cache (for caching the queries results) ...but cache for the actual 
> queries themselves, for the query tree generated by django, the Query object 
> itself.
>
> Has anyone thought of this? Much in the same way the cache loader for 
> templates works, but for queries?

I'm not sure if anyone else has suggested it -- it's certainly an idea
worth exploring.

I have two questions/concerns.

 * Why is query construction expensive in the first place?

Caching is certainly a valid strategy for exchanging memory for a CPU
expensive operation. However, there's an old adage that there are only
two hard CS problems -- naming things, caching, and off by one errors.
If we can avoid the need to climb into the tarpit that is caching by
addressing the underlying expensive operation, that would be a better
win IMHO.

In this case, the reason the operation is expensive is that every time
you add a new query clause, the full query tree is duplicated.
Anything that speeds up this duplication process, or minimizes the
need to duplicate, will give you the same gains.

The reason that the query tree is copied is to ensure that chaining
behavior works reliably: e.g.,

q = MyModel.objects.filter(foo=bar)
q1 = q.filter(whiz=bang)
q2 = q.filter(pork=spam)

In this set of queries, q2 and q1 both extend the filter tree
established by q, so they both need to clone the query generated by q.

One suggestion that has been made that we could make it possible to
disable this cloning -- if I *know* that I'm only going to use this
query once, then I should be able to force the optimization and say
"don't bother preserving this query tree, just reuse it". This would
remove the need for a lot of expensive cloning, at the cost of a
side-effect prone (but opt-in) feature flag.

I'm not completely ruling out the fact that caching might also be a
valid strategy here, but I'd be interested in looking at more
fundamental optimzations as well.

 * How do we key the query cache?

You're correct that the constructed trees, independent of values,
should be reusable structures; however, it isn't obvious to me how we
generate a key for the query that can we can then use to inspect the
query cache. There isn't a natural key (that I can see); short of
actually building the tree, I don't see how we can work out which tree
we need to extract from the cache. If you've got a specific API in
mind for 'naming' queries, I'd be interested in seeing details.

Yours,
Russ Magee %-)

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

Re: "Current" timezone in admin

[Aymeric Augustin]

Hello Danny,

On 15 janv. 2012, at 10:10, Danny W. Adair wrote:
> Is there a hook that allows the "current" timezone to be set for
> admin, so that it uses it for datetime display/submission? Maybe a
> middleware that expects a session variable configured/named in
> settings?

Currently, there's no built-in UI for timezone selection. However, I've 
described some ideas, along with sample code, in the documentation:
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#selecting-the-current-time-zone

There's also a sample app here: https://bitbucket.org/aaugustin/django-tz-demo

> With full timezone support I also think it may be worth adding
> timezone to the standard User model, with a default None that falls
> back to settings.TIME_ZONE (and probably another hook to override the
> default choices).


As long as Django doesn't have a schema alteration API, it's difficult to 
change the User model.

There's also the question of how to store timezones in the database. If we 
implemented this feature, we'd have to bless a timezone implementation. pytz is 
pretty much the standard, and it's highly recommended, but it's possible to use 
another implementation of tzinfo classes if you desire.


For these reasons, I think it's better to leave the field open and see what 
emerges. I don't want to bless an implementation of "per-user time zone 
selection" now, because I don't believe we can come up with a sufficiently 
generic one at this point. Maybe when we have more hindsight...

Best regards,

-- 
Aymeric Augustin.


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

Re: Feature request: read-only admin view

[Juan Pablo Martínez]

+1.
This feature is simple and not implies backwards compatibilities or
security problems.
BTW, is very useful.

On Fri, Jan 20, 2012 at 3:02 PM, Chris Wilson  wrote:

> mins only,




-- 
juanpex

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

Re: Ad-hoc Django integration for fault-tolerance

[Alec Taylor]

Thanks, hadn't thought to go with NoSQL. :)

Quick side-note: I received 14 emails on the django-devel list between
30 and 40 minutes ago. Strange, seeing as this one is dated 10 days
ago. Google Groups problem?

On Wed, Jan 18, 2012 at 10:07 AM, Kenneth Reitz  wrote:
> Enjoy: http://guide.couchdb.org/draft/why.html
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/vQegCKmfVvAJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

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

Re: MySQL connection pooling - preferred method??

[Cal Leeming [Simplicity Media Ltd]]

Damn - no thoughts on this from anyone?

On Wed, Jan 25, 2012 at 12:11 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Hi all,
>
> After spending about 30 minutes looking through old tickets, long
> discussion threads and various blogs, I'm still not clear on the MySQL
> connection pooling topic.
>
> To quote Russ: "the capability already exists in third party tools, and
> they're in a position to do a much better job at it than us because it's
> their sole focus" [3]
>
> Could a core dev (or anyone else with experience on this) clarify which
> approach is recommended, on the following conditions:
>
> * Safety (should not cause any strangeness with query cache or ORM)
> * Performance (should avoid causing Django to open a new database
> connection on every request)
>
> I found various ways to accomplish this, one of which was to use
> SQLalchemy[1], another was to stop Django from closing the database
> connection after each query[2].
>
> I'm hoping this thread will also serve as a final answer for anyone else
> looking for clarification.
>
> Many thanks
>
> Cal
>
> [1]
> http://menendez.com/blog/mysql-connection-pooling-django-and-sqlalchemy/
> [2]
> http://stackoverflow.com/questions/1125504/django-persistent-database-connection
> [3]
> http://groups.google.com/group/django-developers/browse_thread/thread/6f1e9c6e81aff1de/bf34e546e4217277?lnk=gst&q=mysql+pooling#bf34e546e4217277
>
>
>

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

MySQL connection pooling - preferred method??

[Cal Leeming [Simplicity Media Ltd]]

Hi all,

After spending about 30 minutes looking through old tickets, long
discussion threads and various blogs, I'm still not clear on the MySQL
connection pooling topic.

To quote Russ: "the capability already exists in third party tools, and
they're in a position to do a much better job at it than us because it's
their sole focus" [3]

Could a core dev (or anyone else with experience on this) clarify which
approach is recommended, on the following conditions:

* Safety (should not cause any strangeness with query cache or ORM)
* Performance (should avoid causing Django to open a new database
connection on every request)

I found various ways to accomplish this, one of which was to use
SQLalchemy[1], another was to stop Django from closing the database
connection after each query[2].

I'm hoping this thread will also serve as a final answer for anyone else
looking for clarification.

Many thanks

Cal

[1] http://menendez.com/blog/mysql-connection-pooling-django-and-sqlalchemy/
[2]
http://stackoverflow.com/questions/1125504/django-persistent-database-connection
[3]
http://groups.google.com/group/django-developers/browse_thread/thread/6f1e9c6e81aff1de/bf34e546e4217277?lnk=gst&q=mysql+pooling#bf34e546e4217277

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

Triage and Reviewing

[Nate]

After contributing the solution to a small problem (#17492), I was
inspired to look for other tickets that I would be able to help on,
either by triaging un-reviewed tickets (#17537, #17561, #17573),
supplying new patches (#14030*, #16735, #17186), or reviewing patches
(#11305, #16955, #17541)

*rebased out of the patch to #11305

I would very much appreciate if someone would be willing to take a
look at those tickets, and give me constructive feedback.  If I can be
more helpful by doing something different, I want to know.

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

runserver stdout and stderr piping problems

[JuhaS]

I was launching manage.py runserver from another app and trying to
capture the output correctly without luck using pipes. Eventually I
narrowed the problem down to two issues. In my opinion they are bugs
but I thought I'd ask for confirmations here before creating a ticket
and patch.

Issue 1: The startup message of development server isn't flushed.

The result is that starting the server from console directly it is
printed correctly during startup, but using pipes the message isn't
flushed until shutdown (Ctrl+C pressed). Since log messages use etderr
(issue 2) they are flushed before the startup message.

Example:

$ python manage.py runserver 2>> output 1>> output  // redirect stderr
and stdout to file named output

[send few http requests]
[press Ctrl+C]

$ cat output

[20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358
[20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358
[20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358
Validating models...

0 errors found
Django version 1.4 alpha 1, using settings 'djangotut.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Since the actual log messages go to stderr (next issue), the startup
message keeps hanging until shotdown when it's eventually printed to
end of the file. I tried with many commands and all showed the same
issue.

Is this a clear bug?

SOLUTION: adding a stdout.flush() to runserver.py fixes this for me.


Issue 2: Log entries about http requests go to stderr

For some reason the log entries go to stderr (for example 'GET //
HTTP...'). Is this a bug, or is there some reason for this?

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

Where should this test be placed

[Aaron Cannon]

Hi all.

Trying to help out with some of the Trac tickets, and wasn't sure
where tests should be placed for this ticket:

https://code.djangoproject.com/ticket/17504

Is there an existing package that it would make sense to use for
testing this particular bit of functionality?

Thanks.

Aaron

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

Feature request: read-only admin view

[Chris Wilson]

Hi all,

I really like how the admin interface does a lot of the work for me in
developing a site with basic CRUD functions, and a few free bonuses
like pagination and list filtering.

I agree with all the comments on #820  requesting this feature (as well as the "view" permission
which goes with it).

This ticket and several others were closed because a design decision
has been made that the admin interface is for admins only, and such a
feature is out of scope. A lot of people believe that it should be in
scope. Therefore I would like to politely request a reconsideration of
this decision.

There are a few very simple things that Django could do to make this
much easier:

* a simple way (e.g. a switch) to make AdminChangeForm or
fieldset.html produce all fields as read-only, without including them
in CustomAdminForm.readonly_fields; (1-2 lines)

* a way to override the default template selection on
ModelAdmin.render_change_form (1 line)

* an easy way to add URLs to AdminSite.get_urls (5 lines if
intergrated? currently requires about 20 lines of external code for a
generic solution)

* an easy way to override the buttons rendered by the submit_row
template tag, such as wrapping it in a {% block submit_block %} in
change_form.html (currently requires copying the whole of
change_form.html to make this change)

In total the (generic) solution requires a few hundred lines of code,
mainly because those features are not present, and would be about 20
lines of code if they were.

Thanks for your consideration,

Cheers, Chris.

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

Model Fields to add in django.contrib.localflavor.ar

[César H . Roldán]

Hi, I have a models.py file to add in django.contrib.localflavor.ar
This file has the same Fields as forms.py but it's to use in models.
Do I need to add a ticket with the attached file? Or I have to follow
another steps?

César

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

ModelForm._post_clean could simply call Model.full_clean

[Chris Wilson]

Hi all,

I proposed this in a comment on #16423 , and then found that it had come up before:

https://code.djangoproject.com/ticket/13100
https://code.djangoproject.com/ticket/13121

and was rejected thus:

 I think model-validation is just not what you want it to
be. It's a step on the way there, but we can't start completely
validating models before we save them without an extended deprecation
plan for the current non-validating behavior. All of the authors and
people familiar with the implementation are busy until after 1.2 is
out, but we should have a conversation on django-dev a week or so
after that happens.

 I'm going to side with Joseph on this one -- he and Honza
spent a long time developing model validation, and I have a lot of
confidence in his design decisions... if you disagree with a decision
we have made, start a thread on django-developers.

I read this, not as a design decision to never do this, but not to do
it before 1.2 was out. It's now well and truly out :)

The only difference, as far as I can see, between
ModelForm._post_clean and Model.full_clean is that validating
uniqueness is optional in the former. It only happens if:

# It is False by default so overriding self.clean() and
failing to call
# super will stop validate_unique from being called.

Is this the right thing to do? The comment doesn't justify the
behaviour, it just describes it, and the logic isn't apparent to me.

ModelForm._post_clean would be much simpler if it just called
Model.full_clean. Yes the documentation would have to be changed again
.

I hope you will consider this change.

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

Add model file to add in django.contrib.localflavor.ar

[César H . Roldán]

Hi, I have a models.py file to add in localflavor.ar.
This file has the same Fields as forms.py but it's to use in models.
Do I need to add a ticket with the attached file? Or I have to follow
another steps?

Thanks

Cesar

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

Re: Ad-hoc Django integration for fault-tolerance

[Kenneth Reitz]

Enjoy: http://guide.couchdb.org/draft/why.html

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

Re: Read only Test Was: Speeding up tests

[Thomas Rega]

Hi,

I am interested in it - could you be so nice and make this available anywhere?

Thanks a lot in advance.

TR

Am 17.01.2012 um 12:04 schrieb Thomas Guettler:

> Hi,
> 
> same subject, but different content:
> 
> we have a lot of tests which are read only. They don't modify the database or
> other files.
> 
> You don't need to flush the database for every test of read only test cases. 
> These tests can be run on production servers, too.
> 
> At the moment, this unittest code is non public. But if there is any 
> interest, we
> could make it public.
> 
> Is anyone interested?
> 
>  Thomas Güttler
> 
> On 16.01.2012 17:46, Anssi Kääriäinen wrote:
>> 
> 
> 
> -- 
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

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

Addition of failed login signal

[Darren Spruell]

Greetings,

As an enhancement to the existing collection of signals I wanted to
propose the addition of a signal for the event of an unsuccessful
login. Currently django.contrib.auth supports user_logged_in and
user_logged_out for successful events. Addition of e.g.
user_failed_login would allow this event to be handled. I'm interested
in logging this as a security event for the application. I've seen
past discussions on the topic of implementing protection against
password guessing attacks. It seems to me that at least having the
signal available would then give some basis for developers to flexibly
implement customized approaches for handling and responding to login
failures.

I've been advised that I can reach some form of similar functionality
by subclassing the auth backend. Does the new signal approach have
merit?

-- 
Darren Spruell
phatbuck...@gmail.com

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

"Current" timezone in admin

[Danny W. Adair]

Hi,
With 1.4 timezone support I was wondering if/how django admin supports
the current user's timezone.
There's no corresponding HTTP header like "Accept-Language" so I guess
the timezone must be set in the session (looked up from a profile or
whatever).

Is there a hook that allows the "current" timezone to be set for
admin, so that it uses it for datetime display/submission? Maybe a
middleware that expects a session variable configured/named in
settings?

With full timezone support I also think it may be worth adding
timezone to the standard User model, with a default None that falls
back to settings.TIME_ZONE (and probably another hook to override the
default choices).

Cheers,
Danny

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

Regarding queries cache...

[Germán M. Bravo]

Regarding queries cache... but not in the way almost everyone usually thinks of 
this cache (for caching the queries results) ...but cache for the actual 
queries themselves, for the query tree generated by django, the Query object 
itself.

Has anyone thought of this? Much in the same way the cache loader for templates 
works, but for queries?

I've come across the need to cache the query tree since it was taking a lot of 
time for django to build the query trees for a few "complex" queries ...and 
once I cached the query tree, I then later only injected to the tree the values 
that were needed for each filter. The problem with my approach is I have to 
cache a query tree for each different set of filters for the query, still 
however, since its uncommon for the number and type of filters (and excludes 
and options) to be dynamic, the cache works.

For example, if I had a query like this:

MyModel.objects.filter(base="base", Q(name__stuff__id__in=[10, 12, 13]) | 
Q(name__stuff__mode="green")).exclude(type__name="plastic")

And I use it *a lot*, django takes too long to build a tree for it every time, 
and that time is ever increasing for more and more implement queries too. 
However, if I cache the tree generated for that particular query with the set 
of filters and excludes, at a later time I can reuse the query object by simply 
injecting the different new values needed into the tree, to be used instead of 
the originals: "base", [10, 12, 13], "green", and "plastic".

I did this in a very crude way, but it worked. It *significantly* reduced the 
time my queries took. For my strategy I created a function to inject said 
values to the query tree.

If anyone funds this interesting, I can elaborate an provide some code.

German M Bravo

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

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[Mark Lavin]

I think Ian demonstrated exactly why this should not go in and that is not
all forms are ModelForms. Imagine writing a REST API which allows for an
optional format parameter for GET requests which is validated by a Django
form. With the inclusion of this proposal all clients would be forced to
specify the format in the GET (even if left blank) or else the form won't
validate. That's not much of an optional field and a large backwards
incompatibility.

On Fri, Jan 13, 2012 at 10:20 AM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:

> 1. How does this proposal effect default values specified on model fields?
> (ModelForm processing)
> 2. Forgive my ignorance but who has the final say if it goes in or not?
> And since it should be a yes what's next?
>
> On Thu, Jan 12, 2012 at 8:40 PM, Tai Lee  wrote:
>
>> Ian,
>>
>> I agree that there are a lot of different ways that form data can be
>> submitted to Django, including near endless combinations of multiple
>> Django forms, multiple HTML forms, AJAX, etc.
>>
>> If we reduce the scope of our discussion and consider only a Django
>> form (forgetting HTML forms and AJAX) and two possible scenarios:
>>
>> 1. Partial form data is bound to a Django form, and it is not expected
>> to result in a call to the form's `save()` method and a change to the
>> database. It is only intended to examine the form's validation state
>> relating to the partial data that is bound to the form. In this case,
>> the proposed change should have no impact.
>>
>> 2. Full form data is bound to a form, and it IS expected to validate
>> and result in a call to the form's `save()` method and a change to the
>> database. In this case, why would we ever want to assume that a
>> character field which has no bound data, is actually bound to an empty
>> string?
>>
>> This is a dangerous assumption, I think. If we intend to obtain
>> complete data from the user, bind it to a form and save it to the
>> database, we should be sure (as much as we can be) that the data is
>> actually complete.
>>
>> Take the following pure Django example:
>>
>> {{{
>> class Profile(models.Model):
>>first_name = models.CharField(blank=True, max_length=50)
>>last_name = models.CharField(blank=True, max_length=50)
>>address = models.CharField(blank=True, max_length=50)
>>
>> class ProfileForm(ModelForm):
>> class Meta:
>>model = Profile
>>
>> profile = Profile.objects.create(first_name='Tai', last_name='Lee',
>> address='Sydney')
>> form = ProfileForm({}, instance=profile)
>> if form.is_valid():
>>form.save()
>> }}}
>>
>> The profile will have no first name, last name or address. The form
>> will produce no validation errors and will save the updated model to
>> the database.
>>
>> This is very surprising and counter-intuitive to me.
>>
>> I think the only time we could safely make the assumption that fields
>> with empty string values will be omitted by the UA is when we are
>> confident that the source of the form data also makes a similar
>> assumption that the back-end will re-normalise those missing fields
>> back to an empty string.
>>
>> I'd be surprised if any UAs actually do make that assumption, because
>> the way Django treats missing character fields does not appear to be
>> based on any spec, and Django is not the only form processing back-end
>> (or even the most popular one).
>>
>> I'm not sure I follow your simplest case example of one HTML form in a
>> browser window and one Django Form in a view. If optional fields are
>> left off the HTML form deliberately, without change the Form class or
>> the view code, this is exactly when data loss will currently occur. I
>> think you are confusing optional as in "may not be specified by the
>> user" with optional as in "may not be processed by the form"?
>>
>> Cheers.
>> Tai.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[Mark Lavin]

> If optional fields are
> left off the HTML form deliberately, without change the Form class or
> the view code, this is exactly when data loss will currently occur.
> I think you are confusing optional as in "may not be specified by the
> user" with optional as in "may not be processed by the form"?

I think it would be more accurate to call this developer error rather
than a data loss bug in Django. If you are defining forms in this way
you are exposing all the model fields to be changed by the form. You
shouldn't be defining forms with fields you don't want changed.
Imagine this form:

{{{
from django import forms
from django.contrib.auth.models import User

class UserForm(forms.ModelForm):
 class Meta(object):
 model = User
}}}

Look innocent? It's not. Even if you don't render the is_staff or
is_superuser fields they can still be changed if they are given in the
POST. That means exposing this form can allow changing a user to a
superuser. Don't trust data from the client and be explicit about the
fields you want to expose for the form to change. This is why the
'fields' and 'exclude' Meta options exist.

Best,

Mark

On Jan 12, 9:40 pm, Tai Lee  wrote:
> Ian,
>
> I agree that there are a lot of different ways that form data can be
> submitted to Django, including near endless combinations of multiple
> Django forms, multiple HTML forms, AJAX, etc.
>
> If we reduce the scope of our discussion and consider only a Django
> form (forgetting HTML forms and AJAX) and two possible scenarios:
>
> 1. Partial form data is bound to a Django form, and it is not expected
> to result in a call to the form's `save()` method and a change to the
> database. It is only intended to examine the form's validation state
> relating to the partial data that is bound to the form. In this case,
> the proposed change should have no impact.
>
> 2. Full form data is bound to a form, and it IS expected to validate
> and result in a call to the form's `save()` method and a change to the
> database. In this case, why would we ever want to assume that a
> character field which has no bound data, is actually bound to an empty
> string?
>
> This is a dangerous assumption, I think. If we intend to obtain
> complete data from the user, bind it to a form and save it to the
> database, we should be sure (as much as we can be) that the data is
> actually complete.
>
> Take the following pure Django example:
>
> {{{
> class Profile(models.Model):
>     first_name = models.CharField(blank=True, max_length=50)
>     last_name = models.CharField(blank=True, max_length=50)
>     address = models.CharField(blank=True, max_length=50)
>
> class ProfileForm(ModelForm):
>     class Meta:
>         model = Profile
>
> profile = Profile.objects.create(first_name='Tai', last_name='Lee',
> address='Sydney')
> form = ProfileForm({}, instance=profile)
> if form.is_valid():
>     form.save()
>
> }}}
>
> The profile will have no first name, last name or address. The form
> will produce no validation errors and will save the updated model to
> the database.
>
> This is very surprising and counter-intuitive to me.
>
> I think the only time we could safely make the assumption that fields
> with empty string values will be omitted by the UA is when we are
> confident that the source of the form data also makes a similar
> assumption that the back-end will re-normalise those missing fields
> back to an empty string.
>
> I'd be surprised if any UAs actually do make that assumption, because
> the way Django treats missing character fields does not appear to be
> based on any spec, and Django is not the only form processing back-end
> (or even the most popular one).
>
> I'm not sure I follow your simplest case example of one HTML form in a
> browser window and one Django Form in a view. If optional fields are
> left off the HTML form deliberately, without change the Form class or
> the view code, this is exactly when data loss will currently occur. I
> think you are confusing optional as in "may not be specified by the
> user" with optional as in "may not be processed by the form"?
>
> Cheers.
> Tai.

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

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[alej0]

On 12 ene, 14:07, Ian Clelland  wrote:
> On Thu, Jan 12, 2012 at 1:02 AM, Tai Lee  wrote:
> > Donald,
>
> > Thanks for sharing your feedback with everyone.
>
> > I do believe that there should be some kind of validation error or at
> > least a loud warning to the console or logs when a form is bound to
> > incomplete data. The only time when this should occur is for
> > "unsuccessful controls" such as unchecked radio buttons and
> > checkboxes. These shouldn't be a problem for Django, which already
> > normalises no value for a checkbox to False and any value for it to
> > True.
>
> > I'm not sure that there is a widespread practice of submitting partial
> > forms with JS and still expecting the entire form to validate and save
> > is widespread, or even valid according to the RFC and HTML4 specs
> > which expect every successful control to be included in the form data.
>
> You are using the word 'form' in two different contexts here -- There is
> the HTML , on the web page that a user can interact with -- this is
> simply a (mostly) formalized way for a user to submit data to a web
> service. (I say 'mostly' because, as we are discovering, there are edge
> cases where the handling of missing data is not completely specified.)
>
> Secondly, there is the Form object that exists with a Django application.
> This is the only form that we have complete control over, and it is the
> only place that we get to say that data is or is not 'valid'.
>
> There is definitely not a one-to-one correspondence between these two
> forms, and on the web, we can't assume that we have complete control over
> both of them. On the one hand, the HTML form is not the only way for a GET
> or POST request to be submitted. We need to consider, at least:
>
> - Modern, mainstream, buggy web browsers, like Chrome or Firefox
> - Older, mainstream, buggy web browsers
> - Non-mainstream web browsers
> - Other HTML-based User-Agents
> - Other REST-based applications
> - JavaScript submitting AJAX requests with data serialized from an object
> (not a form.submit() call), from any number of frameworks
> - curl / wget command-line interfaces
> - Python urllib / httplib requests (and other languages' equivalents)
> - URL query parameters
>
> Many of these would never even see or parse an HTML  element, but
> they can all still provide data which will be used to construct a Django
> Form. We absolutely cannot claim to have the same level of confidence in
> the behaviour of these that we do by a reading of the RFC and an
> examination of the output from recent versions of Firefox and Chrome.
>
> And then, on the other side, data that comes into a view may be handled by
> multiple Form objects -- it's not uncommon to render fields in an HTML form
> that are going to be handled (or not) by several Django Forms.
>
> Even in the simplest case -- one HTML form, in a browser window, and one
> Django Form in a view -- it may even be the case that several fields were
> left off of the HTML form deliberately, because the same Django view and
> Form are also used by different pages on the site. In this case, I *want*
> to declare the fields to be optional, and then choose how to handle it
> after determining that the presented form fields are valid. With this
> proposal, I won't be able to, without subclassing the form or providing
> different views to handle each subset of data that I need to be able to
> accept.
>
> > Sure, I can see that forms could be fully or even partially submitted
> > via JS to perform AJAX validation in real time, but I don't see how
> > the form as a whole being invalid and validation errors on the missing
> > fields would impact that.
>
> The problem is that AJAX (or any number of other methods) could be
> assembling data that should validate (ie, not for ajax validation, but with
> the intention of actually submitting data), and it may not be easy (or
> possible) to match the handling of null / blank / undefined values to what
> a browser would do.
>
> Not having the ability to get past a Django-mandated ValidationError would
> certainly impact the user experience in this case ;)
>
> --
> Regards,
> Ian Clelland
> 

Hi all,

I've looked carefuly to the example Tom posted and if I undertand the
situation correctly, ther is no problem if a field is missing in the
HTML form, there are to cases you can pass request.POST to a form

1. You are *creating* an object, so if a field is missing, no data is
going to be lost
2. You are *updating* an object, so you need to pass 'instance' to the
form class, doing this only the fields in 'data' are going to be
changed

in both cases you pass request.POST to the form containing only the
fields specified in the HTML, so if you forget a field it won't be
part of request.POST and there is no way your modelform "knows" that.

I've created this project to test this: 
https://github.com/alej0varas/learn-django,
it uses Django 1.3.1, the important code is in "missingdataform/oneapp/
tests.py".

Rega

Wrong annotation when using ordering in meta options

[hovo]

Hi,

I've recently faced to an issue, which I believe is a wrong behavior.
Suppose I have the following model:

class ClassA(models.Model):
date_f = models.DateField()
char_f = models.CharField(max_length=10)

And suppose I have 3 entries in this model:
('2011-11-1', string1),
('2011-12-1', string1),
('2011-12-1', string2)

To calculate counts for each "char_f" field:
ClassA.objects.values("char_f").annotate(count=Count('char_f'))

The result is:
[{'char_f': u'string1', 'count': 2}, {'char_f': u'string2', 'count':
1}]


But when I added ordering in ClassA model

class ClassA(models.Model):

class Meta:
ordering = ("date_f",)

and ran the same query:
ClassA.objects.values("char_f").annotate(count=Count('char_f'))

I've got the following
[{'char_f': u'string1', 'count': 1}, {'char_f': u'string1', 'count':
1}, {'char_f': u'string2', 'count': 1}]

I think the ordering should somehow be ignored in such cases, to
prevent it appearing in sql query
What do you think, is this a correct behavior?

Thanks,
Hovo

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