Loading timezone naive data into your test database with USE_TZ = True

[Robert Rollins]

I have a legacy database from which my Django application must migrate data 
into a Django database. The relevant dates fields are actually TIMESTAMP 
columns in the database, but something (perhaps Django, or python's MySQL 
driver?) loads these columns as timezone naive datetime objects, rather 
than integers. So I wrote my migration code under the assumption that the 
dates coming out of the legacy database are timezone naive.

Unfortunately, now that I'm trying to write tests for this migrator, I 
can't find any way to load timezone naive datetimes into my test legacy 
database. I can't use integer timestamps, because the DateTimeField doesn't 
accept that kind of input (I get a JSON serialization error when I try), so 
I'm using datetime strings like this: "2014-08-01T00:00:00" in my fixture. But 
regardless of whether or not I include a UTC offset in the string, the 
datetime objects that come out of the database during my tests are somehow 
timezone aware. This causes my code to crash because it calls make_aware(), 
which throws ValueError('Not naive datetime (tzinfo is already set)'). 

It seems like having USE_TZ = True is forcibly making my fixture dates 
timezone aware, which I don't want. But USE_TZ will be True during the 
actual migration, so I can't just turn it off during the tests. So how can 
I load timezone naive dates into my test database?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cf3179cd-afdf-484a-9a78-8a84fb46dc76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] django-synth, a bridge to Synth's C++ template engines

[Vladimir U.]

Alvaro J. Genial 

It would be great if someone with C++ backgrounds could participate in the 
development of fast Json Encoderr/Decoder - 
https://github.com/esnme/ultrajson (They license similar to Apache and it 
seems they moved away from development of the project)

Given the fact that javascript client frameworks are becoming more and more 
functional in nowadays, and also given the fact that all the work of 
rendering lays on the browser(that with new versions are getting faster), 
it seems to me, this is a very good direction to be able to deliver json to 
them as fast as it could be.

Sorry for offtopic and thanks for your efforts!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ed53e40-c406-473d-8ae8-f46164e85b02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: add a get_for_template method to ContextList

[germano guerrini]

Hi Florian, thanks for your reply.

I clearly didn't express myself properly, so let me try again with a simple 
example.

Suppose you are dealing with a detail view, whose context has an "object" 
key that refers to the object being displayed. Then, in the rendered 
template, you might have an inclusion tag that defines another context with 
an "object" key that refers to a different object (maybe one related to the 
"main" one). I don't see this as a bug, otherwise every tag should be aware 
of all the views (contexts and templates) where it is going to be used. 
Sure enough, if the tag takes the context, it is its responsibility to push 
and pop from the stack, but that's not what I was talking about.

The fact is that when the test client gets a page, for every template that 
gets rendered, the store_rendered_templates is called through a signal and 
the context appended to the ContextList. This list is then flattened when 
you try to get an item from one of the context, and if you have multiple 
context with the same key, the first one rendered will be the one that you 
get, given the current implementation of ContextList.__getitem__.

Hope that clears it up: ContextList is a list of dictionaries and I think 
it's not safe to assume that there are no overlapping keys - and probably 
it was already a knows "issue" since the keys method returns a set.

Let me know if I completely missed something else,
Germano

On Monday, September 15, 2014 6:35:23 PM UTC+2, Florian Apolloner wrote:
>
> On Monday, September 15, 2014 3:24:19 PM UTC+2, germano guerrini wrote:
>>
>> I'd like to bump this. While there might be better solutions, I think the 
>> issue is not so wacky after all.
>>
>
> To be honest, I don't see an issue here at all. What the view returns 
> should end up in the template. If tags/whatever in your template override 
> variables at will that's a bug in your application imo. Also your code 
> example fails to show where the key is overridden -- ie an include wouldn't 
> override cause the stack is popped after the include. Do you have a 
> concrete example causing this "issue"?
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/93700e14-5cf0-45dc-8014-00810257a693%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.