Re: Why does transaction management only commit on is_dirty?

2010-10-22 Thread Christophe Pettus 

On Oct 22, 2010, at 4:01 PM, Jacob Kaplan-Moss wrote:
> It's a bug: http://code.djangoproject.com/ticket/9964.
> 
> Looks like the patch there is OK, but still needs some work (there's a
> couple of TODOs still).

On it! :)

--
-- Christophe Pettus
   x...@thebuild.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-develop...@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: Why does transaction management only commit on is_dirty?

2010-10-22 Thread Alex Gaynor 
On Fri, Oct 22, 2010 at 7:01 PM, Jacob Kaplan-Moss  wrote:
> On Fri, Oct 22, 2010 at 5:59 PM, Christophe Pettus  wrote:
>> Why does transaction management only commit on is_dirty?
>
> It's a bug: http://code.djangoproject.com/ticket/9964.
>
> Looks like the patch there is OK, but still needs some work (there's a
> couple of TODOs still).
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

Those patches are all well out of date, so if this is something you're
interested in, fixing that up would be a good start.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Why does transaction management only commit on is_dirty?

2010-10-22 Thread Jacob Kaplan-Moss 
On Fri, Oct 22, 2010 at 5:59 PM, Christophe Pettus  wrote:
> Why does transaction management only commit on is_dirty?

It's a bug: http://code.djangoproject.com/ticket/9964.

Looks like the patch there is OK, but still needs some work (there's a
couple of TODOs still).

Jacob

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

Why does transaction management only commit on is_dirty?

2010-10-22 Thread Christophe Pettus 
Why does transaction management only commit on is_dirty?

I realize that the answer to this question is, "Why commit if there are no 
changes to the database?", but it's a bit more complicated than that.

Let's assume a reasonably common case:

1. psycopg2 + PostgreSQL.
2. Transaction middleware enabled, or @commit_on_success decorator.
3. Read-only view function.

In this case, psycopg2 will begin a transaction on the first database read, but 
no COMMIT will ever be sent to the database.  Until the connection actually 
closes, this means that the connection will be in  state 
on the PostgreSQL server, an expensive state to be in.  (A pile-up of  connections is a pretty common occurrence in Django applications, 
in my experience.)

It seems that this problem is trivially fixed by always committing in the 
places that a commit depends on is_dirty().  The commit should be near-free on 
any back-end, since there are no changes, and it eliminates the IIT issue on 
PostgreSQL (and perhaps other problems on MySQL that I'm not as familiar with).

What am I missing?
--
-- Christophe Pettus
   x...@thebuild.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-develop...@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: Using jQuery.noConflict() instead of jQuery.noConflict(true) in contrib.admin

2010-10-22 Thread Chuck Harmston 
A good

Moreover I wont' be able to use any jQuery plugin (that directly
> references `jQuery`) in the admin (without hacking with
> ModelAdmin._media), because the `jQuery` object does not exist. I am
> forced to include jquery twice ...


Per the jQuery docs , plugins
should *not* directly reference the jQuery object; they should do it in a
scope-controlled closure executed at creation with jQuery passed to it as a
parameter. This way, plugins can safely use the $ shortcut without worrying
about whether or not noConflict mode is on, whether it is assigned to a
separate namespace (like django.jQuery), etc; you simply need to change the
parameter passed to the closure. In the case of django.jQuery, it should
look like this:

(function( $ ){
$.fn.myPlugin = function() {
this.each(function() {
this.doSomething();
});
};
})( django.jQuery );

- CH

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

2010-10-22 Thread Mikhail Korobov 
Hi Chris,

I don't see anything harmful neither in
django.contrib.messages.middleware.MessageMiddleware nor in
django.test.testcases.assertContains.
Messages middleware passes response as-is and assertContains reads
'content' attribute and thus forces the baking.

at lest the following test case forks fine for me:

class AssertTestCase(TestCase):
def test_assert_contains(self):
request = RequestFactory().get('/')
template = Template('foo')
response = TemplateResponse(request, template)
self.assertContains(response, 'oo')

Can you please provide more details?

On 23 окт, 00:21, SmileyChris  wrote:
> In my use of TemplateResponse in a real project, we encountered two
> gotchas that I can think of off the top of my head:
>
> 1. You need to explicitly bake the response if you are testing using
> assertContains
> 2. You need to explicitly bake the response before the
> contrib.messages middleware
>
> On Oct 23, 1:32 am, Russell Keith-Magee 
> wrote:
>
>
>
> > On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov  
> > wrote:
> > > Russell's comments were helpful in discovering the edge case.
> > > _set_content behaves differently for baked and non-baked responses:
>
> > > response = render(request, Template('foo'))
> > > response.content = 'bar'
> > > print response.content    # 'foo'
> > > response.content = 'baz'
> > > print response.content    # 'baz'
>
> > > This is confusing so I think responses should be marked as baked in
> > > _set_content, not in force_bake.
>
> > > The patch that should resolve this concern and Russell's concerns
> > > regarding the 
> > > tests:http://bitbucket.org/kmike/django/changeset/00f8be464749
>
> > > I'll take a look at docs and generic views integration later.
>
> > > Should new generic views return TemplateResponse by default?
>
> > I would have thought so. Is there a compelling reason why CBV's
> > shouldn't return a TemplateResponse?
>
> > 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-develop...@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.

Using jQuery.noConflict() instead of jQuery.noConflict(true) in contrib.admin

2010-10-22 Thread tyrion-mx 
1) contrib.admin places jQuery in its own namespace `django.jQuery`.
In this way other jQuery instances should not conflict with it.
2) It also removes the dollar sign AND the `jQuery` object from the
global scope.

*I think* removing the `jQuery` object is not necessary because it
*should* not conflict with any other jQuery instance.

If an admin customization that uses jQuery is loaded, as it should,
after the contrib.admin's javascript, its `jQuery` object will
override the django's one, and django will still be able to use jQuery
with `django.jQuery`.

If an admin customization is loaded before the contrib.admin's
javascript, it *should not* work anyway even if we removed jQuery from
the global scope. That's because jQuery.noConflict(true) removes the
jQuery object from the global scope, but doesn't prevent it to be
created and attached to window (thus overwriting the user's one).

Moreover I wont' be able to use any jQuery plugin (that directly
references `jQuery`) in the admin (without hacking with
ModelAdmin._media), because the `jQuery` object does not exist. I am
forced to include jquery twice ...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #13717: What to do next?

2010-10-22 Thread Jacob Kaplan-Moss 
On Fri, Oct 22, 2010 at 11:21 AM, Silvio  wrote:
> I opened ticket #13717, and it seems to be reproducible by other
> people. Someone contributed a patch, but the ticket is "stuck" because
> it needs tests.
>
> I would really like to see this fixed by 1.3, so I'd be more than
> happy to write these and submit them. But I'm not sure in which file
> the tests belong. I'd appreciate any pointers.

Yeah, sorry about that -- the test suite organization is a bit of a
mess. The general idea when you're adding new tests is that you'd
ideally like to group 'em with other tests of the same functionality.
In the (increasingly rare) case that the feature you want to test
isn't covered yet you can make a new test app for it.

What I usually do when I'm looking for the correct place to add tests
is to grep [1] over the existing test suite looking for existing code
that already covers the same place. If I search for "unique_for" in
the existing test suite, I find that string in the following files:

tests/modeltests/model_forms/models.py
tests/modeltests/model_forms/tests.py
tests/modeltests/model_formsets/models.py
tests/modeltests/validation/models.py
tests/modeltests/validation/test_unique.py

That last file, "test_unique.py" seems like a good candiate, and if I
crack it open I see test functions like
test_unique_for_date_exclusion() and
test_unique_for_date_gets_picked_up(), so seems like that'd be a
pretty good place for the tests for #13717/

Thanks for helping out!

Jacob

[1] Ack, actually: http://betterthangrep.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-develop...@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.

#13717: What to do next?

2010-10-22 Thread Silvio 
Hey guys,

I opened ticket #13717, and it seems to be reproducible by other
people. Someone contributed a patch, but the ticket is "stuck" because
it needs tests.

I would really like to see this fixed by 1.3, so I'd be more than
happy to write these and submit them. But I'm not sure in which file
the tests belong. I'd appreciate any pointers.

Thanks,

Silvio

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

2010-10-22 Thread Tom Evans 
On Thu, Oct 21, 2010 at 9:04 PM, Jacob Kaplan-Moss  wrote:
> On Thu, Oct 21, 2010 at 1:25 PM, Waldemar Kornewald
>  wrote:
>> Thanks a lot for the clarification. So, then the "bad batteries" part
>> in Eric's talk "Why Django sucks and how we can fix it" doesn't
>> receive much agreement within the Django core team?
>
> I think that's kind of irrelevant: people complaining about "bad
> batteries" are arguing that the solution should be "good batteries",
> not "no batteries".
>

(I don't particularly have an objection to contrib.staticfiles)

I think that things should only be in contrib if they are universally
'The One True Way'. For instance, there are not other admin suites out
there clamouring to be django's admin, nor is there anyone out there
thinking that generic keys should be implemented in a different manner
or that pagination isn't doing the right thing.

On the other hand, schema migration has a number of approaches (I
personally use South), there are many resource bundlers available. I
personally don't think that things should be going into contrib just
because they fill a hole, but because they truly are the 'correct'
implementation.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

2010-10-22 Thread Russell Keith-Magee 
On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov  wrote:
> Russell's comments were helpful in discovering the edge case.
> _set_content behaves differently for baked and non-baked responses:
>
> response = render(request, Template('foo'))
> response.content = 'bar'
> print response.content    # 'foo'
> response.content = 'baz'
> print response.content    # 'baz'
>
> This is confusing so I think responses should be marked as baked in
> _set_content, not in force_bake.
>
> The patch that should resolve this concern and Russell's concerns
> regarding the tests: http://bitbucket.org/kmike/django/changeset/00f8be464749
>
> I'll take a look at docs and generic views integration later.
>
> Should new generic views return TemplateResponse by default?

I would have thought so. Is there a compelling reason why CBV's
shouldn't return a TemplateResponse?

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

csrf_token on 404 page

2010-10-22 Thread Gert Van Gool 
I'm unsure whether this is a bug or not. So I'm checking here first.
But it seems impossible to use {% csrf_token %} on a 404 page?
On a 500 page, it's works though.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

2010-10-22 Thread Ivan Sagalaev 

Hi Russel,

On 10/22/2010 05:20 AM, Russell Keith-Magee wrote:

Jacob has already marked #9886 RFC, and on first inspection, the patch
looks good to me too; I want to have a closer look before I commit,
though. If you want to proceed assuming that #9886 will be committed
(i.e., make the fix for #14523 have #9866 as a prerequisite), I doubt
it would be wasted effort.


I didn't feel it would be wasted :-). I was going to start doing the new 
patch on top of my local bzr branch with #9886 applied (arent' DVCSes 
awesome?). What I meant is that I didn't want to actually attach a diff 
file to the ticket yet because it has chances of not being applicable 
against trunk.



Regarding the second problem you describe -- unless I'm mistaken,
Simon's TemplateResponse addresses this with his "baking" concept; a
response is baked the first time it is iterated or otherwise
evaluated.


The problem is that this iteration may (and does) happen after response 
is returned from the handler — and hence outside the `try .. except`. 
The point is to call baking explicitly right before the return.


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