USE_TZ related warnings caused by fixture loading

[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 DateTimeField timestamp.

Does this mean that fixture loading needs to be modified to account for the 
new timezone code, or was is this just a side effect of keeping fixture 
loading backward-compatible?

-- 
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/-/oGCVFF3Gn68J.
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: USE_TZ related warnings caused by fixture loading

[Aymeric Augustin]

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 DateTimeField timestamp.
>

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.

Does this mean that fixture loading needs to be modified to account for the
> new timezone code, or was is this just a side effect of keeping fixture
> loading backward-compatible?


The code is backwards compatible: assuming you haven't changed TIME_ZONE,
you will get the data you expect in the database. The warning is just a
hint that you should regenerate your fixture.

One of the goal of time zone support was to ensure that developers don't
accidentally perform "unsafe" (under-specified) operations. Interpreting
the naive datetime stored in your fixture in an aware environment is
unsafe. Whenever this sort of thing happens, Django raises a warning.

 --
Aymeric.

-- 
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: USE_TZ related warnings caused by fixture loading

[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 able to interpret
it yet.

Can we possible change the warning to be more clear about what's causing
it? Or at the very least add a note to the release docs about upgrading
fixtures? It's an annoying warning, and the message (to me) doesn't
point very clearly at the cause.

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-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: call_command; add *.pyc and *.pyo files to commands list

[Carl Meyer]

On 02/29/2012 09:07 PM, bhuztez wrote:
> IMHO, no extra support for them is required. Simply add support for
> PEP 302 importers, Django will find management commands in pyc/pyo
> files.
> 
> I improved patch for #14087 weeks ago, which add support for PEP 302
> importers. I am just wondering why the core team did not even bother
> to review it.

I looked over your patch briefly; I don't have time for a full review
right now (probably after 1.4 is released), but in general I think the
direction you're taking is the right one.

The way Django currently finds management commands is pretty poor,
because it makes all kinds of assumptions about the filesystem layout of
Python packages that aren't valid (which is why it doesn't support
zipped eggs, namespace packages, etc.) Adding direct support for pyc
files into Django is a non-starter, because it takes us even further
down the bad-assumptions road (pyc files are an internal CPython
implementation detail, and in Python 3 they've already been moved into a
__pycache__ subdirectory). Your approach, which moves away from the
invalid assumptions and towards using real Python APIs (like
pkgutil.iter_modules) is, I think, the right one.

Carl



signature.asc
Description: OpenPGP digital signature

Re: USE_TZ related warnings caused by fixture loading

[Aymeric Augustin]

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 able to interpret
> it yet.
>
> Can we possible change the warning to be more clear about what's causing
> it? Or at the very least add a note to the release docs about upgrading
> fixtures? It's an annoying warning, and the message (to me) doesn't
> point very clearly at the cause.


Sure, I'll take care of this.

-- 
Aymeric.

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

Pretty Django model instaces updating

[Kee]

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

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

[Marc Tamlyn]

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 view which creates an object related to a parent. This is easily 
achievable by overriding the form_valid method of CreateView and excluding 
the foreign key from the form. However, the view should return a 404 if the 
related object specified by the url does not exist. Written as a non class 
based view, the natural flow is to try to load the parent object from the 
database, handle it as necessary, and then split paths depending on whether 
we have a get or post. It is currently very difficult to emulate this 
without duplication of some sort.

My proposal is that we add a process_request (or similar name) method which 
is called by the dispatch method immediately before the method handler is 
called. (i.e. 
here).
 
This would then allow pre-processing and sanity checking of the request 
object, using the args, kwargs and request that have been saved on the 
class, before delegating off the the respective views. The method should 
return None or an HttpResponse subclass. If it returns something, then we 
return that directly from the dispatch method.


I can supply some code (my proposal is pretty simple I think) but I thought 
I'd open it up for discussion first.

Marc Tamlyn

-- 
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/-/3gP1cLOL9usJ.
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: Pretty Django model instaces updating

[Carl Meyer]

Hi Kee,

On 03/01/2012 11:24 AM, Kee wrote:
> This helper could be used as an instance method in
> django.core.models.Model class:
>  https://gist.github.com/1951748

Thanks for the suggestion. I agree that that's a useful pattern and one
I frequently use myself. The problem is that the model instance
namespace is a precious resource, and using up any more of it than we
already do can easily lead to backwards-compatibility problems. In this
case, I don't think turning a one-liner into a shorter one-liner
justifies using up more of that namespace.

Carl



signature.asc
Description: OpenPGP digital signature

Re: Pretty Django model instaces updating

[Meir Kriheli]

Hi,

On Thu, Mar 1, 2012 at 9:29 PM, Carl Meyer  wrote:

> Hi Kee,
>
> On 03/01/2012 11:24 AM, Kee wrote:
> > This helper could be used as an instance method in
> > django.core.models.Model class:
> >  https://gist.github.com/1951748
>
> Thanks for the suggestion. I agree that that's a useful pattern and one
> I frequently use myself. The problem is that the model instance
> namespace is a precious resource, and using up any more of it than we
> already do can easily lead to backwards-compatibility problems. In this
> case, I don't think turning a one-liner into a shorter one-liner
> justifies using up more of that namespace.
>
> Carl
>
>
IIRC, it won't call the instance's save() method nor fire model related
signals,
which isn't the expected behaviour from an instance method.

Cheers
-- 
Meir Kriheli
http://meirkriheli.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.

Re: Pretty Django model instaces updating

[Anssi Kääriäinen]

On Thursday, March 1, 2012 9:29:34 PM UTC+2, Carl Meyer wrote:
>
> 
>
> Thanks for the suggestion. I agree that that's a useful pattern and one
> I frequently use myself. The problem is that the model instance
> namespace is a precious resource, and using up any more of it than we
> already do can easily lead to backwards-compatibility problems. In this
> case, I don't think turning a one-liner into a shorter one-liner
> justifies using up more of that namespace.
>
> Carl
>
I suggest implementing .save(only_fields=list_of_fields).

That should not be hard to implement and will not consume the namespace of 
models. Signals are fired properly. In addition, update() would be a bit 
strange instance method: it updates the specified fields by the kwargs (the 
instance's field values do not matter). In addition, after the update the 
instance's fields are not updated to reflect what was just saved.

 - Anssi

-- 
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/-/t7tJffdFeg4J.
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: Newline stripping in templates: the dnl way

[Leon Matthews]

> 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?  From my perspective it's a
big win, and reading the bug notes, the issues -- backwards
combatibility, docs, tests -- seem to have been addressed.

It looks like a lot of work looks went into this patch, why did it stall?

Leon

-- 
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: Newline stripping in templates: the dnl way

[Carl Meyer]

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 Checkin. If you'd like to see it in
(post 1.4 at this point, of course), feel free to do that!

Carl



signature.asc
Description: OpenPGP digital signature

Re: Newline stripping in templates: the dnl way

[Leon Matthews]

> 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 realised after posting that my question was
particularly poorly timed, given where we are in the release cycle.  I
apologise for that -- I was overcome with excitement to find that
somebody had already written the patch I wanted!

-- 
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: Pretty Django model instaces updating

[Kee]

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 agree that that's a useful pattern and one
> > I frequently use myself. The problem is that the model instance
> > namespace is a precious resource, and using up any more of it than we
> > already do can easily lead to backwards-compatibility problems. In this
> > case, I don't think turning a one-liner into a shorter one-liner
> > justifies using up more of that namespace.
>
> > Carl
>
> I suggest implementing .save(only_fields=list_of_fields).
>
> That should not be hard to implement and will not consume the namespace of
> models. Signals are fired properly. In addition, update() would be a bit
> strange instance method: it updates the specified fields by the kwargs (the
> instance's field values do not matter). In addition, after the update the
> instance's fields are not updated to reflect what was just saved.
>
>  - Anssi

-- 
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: Generic edit generic views don't create `fail_silently` messages anymore.

[Russell Keith-Magee]

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 for class based equivalents?
> 
> If it was deliberately omitted then, since function based views are 
> deprecated, the message framework documentation for the `fail_silently` kwarg 
> should be updated to remove the part where it makes reference to generic 
> views using it internally.

To the best of my recollection, it wasn't a deliberate decision to omit these 
messages. It looks like an oversight during development.

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.

no fixtures found error

[froto]

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 ...
Installing indexes ...
No fixtures found.

-- 
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: no fixtures found error

[Karen Tracey]

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 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: no fixtures found error

[froto]

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" 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: Pretty Django model instaces updating

[Tai Lee]

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:
for k, v in kwargs.iteritems():
setattr(self, k, v)
self.save(force_update=True)

This will still fire the `save` signals, and your model instance will
have the new values as well as having them saved to the database.

I think it is also easier than assigning values to each field and then
calling `.save(only_fields[field1, field2])`, which I don't think is
any better than filter().update(). If `save(only_fields=...)` were to
only write specified fields to the database, this might cause
unexpected side effects with `save` signals?

If you don't like the name `update`, or it clashes with something else
in your model namespaces, just use something else.

I don't think this warrants inclusion in Django core.

Cheers.
Tai.


On Mar 2, 8:48 am, Kee  wrote:
> 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 agree that that's a useful pattern and one
> > > I frequently use myself. The problem is that the model instance
> > > namespace is a precious resource, and using up any more of it than we
> > > already do can easily lead to backwards-compatibility problems. In this
> > > case, I don't think turning a one-liner into a shorter one-liner
> > > justifies using up more of that namespace.
>
> > > Carl
>
> > I suggest implementing .save(only_fields=list_of_fields).
>
> > That should not be hard to implement and will not consume the namespace of
> > models. Signals are fired properly. In addition, update() would be a bit
> > strange instance method: it updates the specified fields by the kwargs (the
> > instance's field values do not matter). In addition, after the update the
> > instance's fields are not updated to reflect what was just saved.
>
> >  - Anssi

-- 
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: Pretty Django model instaces updating

[Carl Meyer]

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 then call `save()`.
>   """
>   if kwargs:
>   for k, v in kwargs.iteritems():
>   setattr(self, k, v)
>   self.save(force_update=True)
> 
> This will still fire the `save` signals, and your model instance will
> have the new values as well as having them saved to the database.
> 
> I think it is also easier than assigning values to each field and then
> calling `.save(only_fields[field1, field2])`, which I don't think is
> any better than filter().update(). If `save(only_fields=...)` were to
> only write specified fields to the database, this might cause
> unexpected side effects with `save` signals?

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 that your proposed code does not do.

Carl



signature.asc
Description: OpenPGP digital signature

Re: Pretty Django model instaces updating

[Anssi Kääriäinen]

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, **kwargs):
> > """
> > Updates the fields specified in `kwargs` and then call `save()`.
> > """
> > if kwargs:
> > for k, v in kwargs.iteritems():
> > setattr(self, k, v)
> > self.save(force_update=True)
> > 
> > This will still fire the `save` signals, and your model instance will
> > have the new values as well as having them saved to the database.
> > 
> > I think it is also easier than assigning values to each field and then
> > calling `.save(only_fields[field1, field2])`, which I don't think is
> > any better than filter().update(). If `save(only_fields=...)` were to
> > only write specified fields to the database, this might cause
> > unexpected side effects with `save` signals?
>
> 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 that your proposed code does not do.
>
I should have mentioned that ticket. This is one of the tickets where the 
feature isn't hard to implement. Getting the API exactly correct is hard. 
And keeping the feature restricted is even harder...

 - Anssi

-- 
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/-/aqdLL7PP1AsJ.
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: Pretty Django model instaces updating

[Jeremy Dunck]

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 that your proposed code does not do.

It is also useful in the case where you have fields on the model which
have authoritatively changed, but have other local values which might
be stale.

-- 
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: no fixtures found error

[kenneth gonsalves]

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 place.
-- 
regards
Kenneth Gonsalves

-- 
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: no fixtures found error

[kenneth gonsalves]

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? 
> 
> 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 place.
> -- 
> regards
> Kenneth Gonsalves
> 


-- 
regards
Kenneth Gonsalves

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