Re: no fixtures found error

apologies for this post - I did not notice it was on the dev list. On Fri, 2012-03-02 at 11:58 +0530, kenneth gonsalves wrote: > On Thu, 2012-03-01 at 17:47 -0800, froto wrote: > > I am using statement:python manage.py syncbd,but there is a error > > report:no fixtures found.What's wrong with it?

Re: no fixtures found error

On Thu, 2012-03-01 at 17:47 -0800, froto wrote: > I am using statement:python manage.py syncbd,but there is a error > report:no fixtures found.What's wrong with it? that is not an error message - it is just a statement of fact. Either you have no fixtures, or your fixtures are in the wrong

Re: Pretty Django model instaces updating

On Thu, Mar 1, 2012 at 9:28 PM, Carl Meyer wrote: > The "only_fields" kwarg suggestion comes from ticket 4102, and it is > primarily intended as a performance optimization for large models by > only sending the values of certain fields to the database at all, > something

Re: Pretty Django model instaces updating

On Friday, March 2, 2012 7:28:30 AM UTC+2, Carl Meyer wrote: > > On 03/01/2012 09:46 PM, Tai Lee wrote: > > This is easy to achieve in your own code. Create your own BaseModel > > class that all your models subclass. Instead of using > > `.filter().update()`, do this: > > > > def update(self,

Re: Pretty Django model instaces updating

On 03/01/2012 09:46 PM, Tai Lee wrote: > This is easy to achieve in your own code. Create your own BaseModel > class that all your models subclass. Instead of using > `.filter().update()`, do this: > > def update(self, **kwargs): > """ > Updates the fields specified in `kwargs` and

Re: Pretty Django model instaces updating

This is easy to achieve in your own code. Create your own BaseModel class that all your models subclass. Instead of using `.filter().update()`, do this: def update(self, **kwargs): """ Updates the fields specified in `kwargs` and then call `save()`. """ if kwargs:

Re: no fixtures found error

thanks On 3月2日, 上午11时12分, Karen Tracey wrote: > Please ask questions about using Django on django-users. The topic of this > list is the development of Django itself. > > Karen -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: no fixtures found error

Please ask questions about using Django on django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

no fixtures found error

django+sqlite I am using statement:python manage.py syncbd,but there is a error report:no fixtures found.What's wrong with it? Creating tables ... Creating table books_publisher Creating table books_author Creating table books_books_authors Creating table books_book Installing custom SQL ...

Re: Generic edit generic views don't create `fail_silently` messages anymore.

On 01/03/2012, at 4:47 AM, Simon Charette wrote: > Now deprecated generic create_update function based views (create_object, > update_object, delete_object) use to create silently failing success messages > when the submitted form was valid. > > Was it a design decision to omit this feature

Re: Pretty Django model instaces updating

Fully agree with Anssi Kääriäinen, the best approach is ``only_fields`` for save()`` On Mar 1, 11:45 pm, Anssi Kääriäinen wrote: > On Thursday, March 1, 2012 9:29:34 PM UTC+2, Carl Meyer wrote: > > > > > > Thanks for the suggestion. I

Re: Newline stripping in templates: the dnl way

> Same reason any ticket stalls - it seems that nobody felt strongly > enough about it to put the time into reviewing and thoroughly testing > the patch and marking it Ready for Checkin. If you'd like to see it in > (post 1.4 at this point, of course), feel free to do that! Fair enough. I

Re: Newline stripping in templates: the dnl way

On 03/01/2012 01:28 PM, Leon Matthews wrote: > It looks like a lot of work looks went into this patch, why did it stall? Same reason any ticket stalls - it seems that nobody felt strongly enough about it to put the time into reviewing and thoroughly testing the patch and marking it Ready for

Re: Newline stripping in templates: the dnl way

> I believe that is what has been suggested, and tickets produced by > SmileyChris and worked on by others to that end, at > https://code.djangoproject.com/ticket/2594 That's... quite fantastic. A actual patch for the exactly the behaviour I had in mind. Why was it not commited for 1.3 or 1.4?

Class based views: A standard hook for http-method-independent code

Hi all, Apologies if this has been raised before. I've had a look around and can't find a good way of doing this with the current code. I regularly have views which rely on some custom code which runs some sanity checking on the request and is independent of method. As an example, consider a

Pretty Django model instaces updating

This helper could be used as an instance method in django.core.models.Model class: https://gist.github.com/1951748 -- 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

Re: USE_TZ related warnings caused by fixture loading

2012/3/1 Jacob Kaplan-Moss > Aymeric Augustin wrote: > > Indeed, a fixture that was generated with USE_TZ = False (or before time > > zone support existed) will raise warnings when it's loaded with USE_TZ = > > True. > > Ahha - I've been seeing that warning and haven't been

Re: USE_TZ related warnings caused by fixture loading

Aymeric Augustin wrote: > Indeed, a fixture that was generated with USE_TZ = False (or before time > zone support existed) will raise warnings when it's loaded with USE_TZ = > True. Ahha - I've been seeing that warning and haven't been able to interpret it yet. Can we possible change the warning

Re: USE_TZ related warnings caused by fixture loading

2012/3/1 Yo-Yo Ma > django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField > received a naive datetime (2012-01-01 00:00:00) while time zone support is > active. > > The above warning is caused by a JSON fixture having "2012-01-01 00:00:00" > for a

USE_TZ related warnings caused by fixture loading

django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField received a naive datetime (2012-01-01 00:00:00) while time zone support is active. The above warning is caused by a JSON fixture having "2012-01-01 00:00:00" for a DateTimeField timestamp. Does this mean that fixture