Re: Proposal: Replace django.contrib.formtools.wizard

On Sep 8, 7:47 pm, Stephan Jäkel wrote: > Hi Scot, > > shacker wrote: > > Not all forms are completed in a single sitting. We have a form with > > more than 100 fields, which takes at least two hours for the user to > > complete. Therefore it's essential that the (authenticated)

Proposal: adding value and display_value to bound fields.

Hello all, This proposal is about adding value and display_value properties to BoundFields (ticket #10427). The value property gives raw data and display_value gives the value in user friendly format. For example for CharField, both value and display_value will be just the raw data. But for

Re: Model translation

On Aug 8, 2:38 am, Anssi Kaariainen <akaar...@cc.hut.fi> wrote: > I don't know if I still have the code somewhere lying around, but as I > said it was a ugly hack that was just barely working for the easy > cases. If somebody is interested there is a patch available at http

Re: Model translation

On Aug 7, 11:34 pm, David Danier wrote: > What about "putting common data into its own model"? I like this > solution, I even like this solution so much I tried to implement it > several times. BUT you cannot get it to use a nice query. Most of the > time you will

Re: Querysets with "only()" and "defer()" slower than without?

On Aug 6, 12:09 am, Jacob Kaplan-Moss wrote: > If you're benchmarking this against a small dataset and an in-memory > database like SQLite I'd fully expect to see the defer/only benchmark > to be slower. That's because every time a QS is chained it needs to be > copied, which

Re: django.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS

As a related problem the manage.py validate seems to do the same thing -- that is import the default connection and do any validation using it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Running doc tests in Django's test suite

I am trying to run some doc tests, but can't figure out how. Specifically I would like to run the doc tests in regressiontests/ forms/widgets.py. Running "./runtests.py --settings=test_sqlite forms" from the tests directory it runs the unit tests (changing them results in failures) but not the

Re: Last call: #11863 (Model.objects.raw)

On Dec 16, 4:34 pm, "Sean O'Connor" wrote: > Nice work Russ!  Got to love when something goes from "nice to have" to > "done". > > Anssi, I don't think I understand your use case.  Even if an unmanaged model > doesn't have a literal table behind it, it needs something

Re: Last call: #11863 (Model.objects.raw)

were populated and marking the non-populated fields as deferred would be optimal in my opinion. One use case where you don't necessary know which fields are populated and which ones aren't is when you have multiple raw() queries defined populating different fields of the model. Anssi Kaariainen --

Re: Public method for getting model field names in order of definition

> Thanks for the example, but that's not a ModelForm. > > Richard Another try, view.py: from django.forms.models import model_to_dict def view(request): data = Foo.objects.all()[0] print data.start form = Example(data=model_to_dict(data)) return render_to_response('t.html',

Re: Public method for getting model field names in order of definition

Sat, 2009-11-21 at 05:57 -0800, Anssi Kaariainen wrote: > > If I am not completely mistaken you can use your ModelForm with > > field.label and field.data to get read-only view of the model. > > I was trying to do something like this today and didn't have any luck. > Do you have

Re: Public method for getting model field names in order of definition

On Nov 21, 6:25 am, Rob Hudson wrote: > But if you wanted to redisplay that information back to the user in a > read-only form, there is no iterative way to do so (as far as I know). >  Instead you must specifically "hard code" each field: > >     >         Field 1 >        

Re: Continuous Integration command

On Oct 18, 8:08 pm, berto wrote: > Sounds like you're interpreting what I'm looking as a feature, a > bug.  :)  I want to write tests and see them fail continually until I > have written the code that makes them pass. Is it possible to autorun only the failing

manage.py reset and custom sql

Hello all, The problem I am trying to solve is this: I have defined some views and corresponding models with managed = False. Now when I issue manage.py reset I get an error because the views block dropping the tables. I need to manually drop the views before I issue manage.py reset. I am

Two simple to fix bugs in 1.1 RC

Hello all, 1) If using postgresql with autocommit = True, and a postgresql version that supports autocommit, first save of a model will fail if it is the first query ran. ("ProgrammingError: no results to fetch"). The problem is that the generated query will not contain "RETURNING id" because

first insert on connection fails (psycopg2, postgresql version__gte 8.2)

Hello all, I think I found a bug in django SVN when using psycopg2 and postgresql version > 8.1. The problem is simple to reproduce: class Foo(): pass $ python manage.py shell >>> Foo().save() # Fails django/db/backends/__init__.pyc in fetch_returned_insert_id(self, cursor) --> 171