[Admin-01] Bulk-edit on changelist page

I've been working on a patch for this ticket, and now have it more or less complete, therefore I'm soliciting review. Firstly, there may be some confusion as to what exactly bulk-edit means, Jacob and I discussed this the other week and we more or less split it into 2 components, the first is

Re: How to help with doc?

On Fri, Jan 16, 2009 at 1:53 PM, Geoffrey Ducharme wrote: > From what I gather, the documentation effort have been mostly voluntary and > not well organized. For example, I don't think there is a mailing list for > documentation feedback. People like you seem to pop

Re: How to help with doc?

On Fri, Jan 16, 2009 at 2:53 PM, Geoffrey Ducharme < geoffrey.ducha...@gmail.com> wrote: > There was some talk on this list about updating the django book a few weeks > ago. There were three people who had manifested interest in obtaining > updated documentation. I don't know if they did anything

Re: How to help with doc?

There was some talk on this list about updating the django book a few weeks ago. There were three people who had manifested interest in obtaining updated documentation. I don't know if they did anything about it, though. I do know that there are a few inconsistencies in the main site

Re: Testing speedup checked in

As another data point, our nightly run of the test suite against Oracle just completed. We see the same test failures we had previously--nothing new--but it was *much* faster as hoped. Python 2.5, Django 1.0.x: 24510 secs. Python 2.5: Django trunk: 3024 secs. Previously, trunk took about ten

Re: Problem with ORM

W dniu 16.01.2009 16:34, varikin pisze: > > On Jan 15, 5:38 pm, Sebastian Bauer wrote: > >> I think ORM supposed to have save insert and update: >> >> save(force_insert=False,force_update=False) >> update() == save(force_update=True) >> insert() == save(force_insert=True)

Re: Problem with ORM

On Jan 15, 5:38 pm, Sebastian Bauer wrote: > I think ORM supposed to have save insert and update: > > save(force_insert=False,force_update=False) > update() == save(force_update=True) > insert() == save(force_insert=True) > > in that situation we could have clean code and

How to help with doc?

I'm an experienced technical writer (10 years at O'Reilly, author of several programming books that have done well, editor of others). I'm now doing Django programming, one site completed and a second on the way. I'd like to contribute to the doc if there's interest in some help from an expert

Re: Testing speedup checked in

On Fri, Jan 16, 2009 at 9:43 AM, Alex Gaynor wrote: > PgSQL is indeed PostgreSQL. Yes, I do still get the failures pre-fast > tests, I guess I'd never run those tests. I would like to say that when I > went back to test that the tests were unbearably slow, so that makes

Re: Sanity check #8306 (cleaning up formfield_for_dbfield), please

On Fri, Jan 16, 2009 at 5:06 AM, Flavio Curella wrote: > Wouldn't it be more granular to allow the overrides on the field name > basis? something like: Hm, I think that's a separate issue: the goal of the patch is to easily make "mixins" providing custom widgets (etc.)

Re: Testing speedup checked in

On Fri, Jan 16, 2009 at 9:13 AM, Ivan Sagalaev wrote: > > I've found it. My fault, as usually :-). But an interesting corner case > too. > > We're using mysql_replicated db backend that basically has two > connections. The first ("master") is active by default and is

Re: Testing speedup checked in

On Fri, Jan 16, 2009 at 9:39 AM, Karen Tracey wrote: > On Fri, Jan 16, 2009 at 9:15 AM, Alex Gaynor wrote: > >> I'm seeing some failures exclusively under PgSQL: >> http://dpaste.com/109831/ . I'm not sure what's causing them, but it's >> just the

Re: Testing speedup checked in

On Fri, Jan 16, 2009 at 9:15 AM, Alex Gaynor wrote: > I'm seeing some failures exclusively under PgSQL: > http://dpaste.com/109831/ . I'm not sure what's causing them, but it's > just the admin views tests, no other ones. > (PgSQL is PostgreSQL ... ?) I see those too,

Re: Testing speedup checked in

On Fri, Jan 16, 2009 at 9:13 AM, Ivan Sagalaev wrote: > > Karen Tracey wrote: > > Hmm, not sure what is going on here. Django's admin_views testscase > > uses client and fixtures, and doesn't have a problem. It should not > > happen that data loaded by one TestCase

Re: Testing speedup checked in

Karen Tracey wrote: > Hmm, not sure what is going on here. Django's admin_views testscase > uses client and fixtures, and doesn't have a problem. It should not > happen that data loaded by one TestCase persists in the database to > another test. TestCase setup starts a transaction and

Re: Testing speedup checked in

On Fri, Jan 16, 2009 at 7:47 AM, Ivan Sagalaev wrote: > > Karen Tracey wrote: > > For the most part this change should be invisible, except for the speed > > improvement when running tests. However, if you have tests that need to > > actually test the effects of

Re: Testing speedup checked in

Ivan Sagalaev wrote: > Karen Tracey wrote: >> For the most part this change should be invisible, except for the speed >> improvement when running tests. However, if you have tests that need to >> actually test the effects of transaction commit or rollback, you will >> now need to use a

Re: Testing speedup checked in

Karen Tracey wrote: > For the most part this change should be invisible, except for the speed > improvement when running tests. However, if you have tests that need to > actually test the effects of transaction commit or rollback, you will > now need to use a django.test.TransactionTestCase

Re: Sanity check #8306 (cleaning up formfield_for_dbfield), please

sorry, wrong snippets ``` # assume years_range = range(2008, 1900) formfield_overrides = { 'body': { 'widget': RichTextEditorWidget() }, 'birthday': {'widget': SelectDateWidget(years=years_range) }, } ``` maybe this is for yet another option, or we can allow something like this (ps: i

Re: Sanity check #8306 (cleaning up formfield_for_dbfield), please

hi, I read the patch in #8306, and looks like formfield_overrides allows to change the default widget only on a field type basis: ``` formfield_overrides = { models.TextField: {'widget': RichTextEditorWidget}, } ``` Wouldn't it be more granular to allow the overrides on the field name