Re: Form Rendering API Proposal

[Chris Beaven]

On Tuesday, June 28, 2011 11:56:41 PM UTC+12, Gregor Müllegger wrote:
>
> However I think these templatetags could go into a thirdparty app.
>
-0, changing a label / help text at least are pretty common cases - the 
template designer shouldn't be at the mercy of the python form settings.
I'm glad that you've thought about this a bit though and agree that just 
getting something working is better than trying to fix all the problems at 
once.
 

> BTW: even without the thirdparty apps it's already possible to change the
> label for a field in an (somehow) easy way. Just extend from the row 
> template
> you use for your other rows in the form and override the {% block label %}.
>
A passing thought is that I wonder if we allow for this inline too, like how 
{% form using  %} works...

> How are HTML classes specified for rows which are required / contain 
> errors?
>
> > (and one more slightly obscure one, probably out of scope...)
>
> This can be achieved in the row template:
>
> 
>
Can't a row technically have more than one field though? I guess it's still 
solvable with a custom template filter or the like, just seems like another 
common case we could account for with some context var passed to the row 
template.
 

> > How does the form in python have knowledge of the widget which the field 
> was
>
> > rendered with as picked by the template?
> > This is critical since building the form's data requires using the 
> widget's
> > value_from_datadict.
>
> I think thats conceptually not possible. We simply can change the widget 
> during
> template rendering time, which makes it impossible to decide in the python
> code with which widget we end up. And theoretically we could even render 
> the
> form twice with different widgets. Or throw the rendered template away 
> without
> using the widget at all.
>

In this case, why do we even have this format: {% formconfig widget 
widgets.Textarea for "comment" %} and the terminology of widgets?
It seems like that should really just boil down to {% formconfig field using 
"some/textarea.html" for "comment" %} and just referring to fields only. A 
widget to me encompasses the backend logic of decoding the data, etc.

I think it'd be a great plus if we *could* make it work for different 
widgets. This would really give power to change forms dynamically at the 
template layer.
I remember thinking a while ago about some kind of widget repository 
available to the templates, combined with a hidden input per field that 
could notify the python form of the alternate widget used (the hidden input 
only used if the widget differed than the default for that field). This 
would allow for the same form to be used with different templates which used 
completely different widgets.

>

-- 
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/-/ZKI7d8x1WbIJ.
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: Python/Django decorators with arguments

[Russell Keith-Magee]

On Wed, Jun 29, 2011 at 12:22 AM, Jigar Tanna
 wrote:
> hey,
>
> I am new to Python and Django, was going through the concept of
> decorators where I came across a special case of using arguments with
> decorators
> Below is the code for memoization where I was looking at the
> concept...
>
> cache = {}
> def get_key(function, *args, **kw) :
>    key = '%s. %s: ' % (function. __module__,function. __name__)
>    hash_args = [ str(arg) for arg in args]
>    hash_kw = [' %s: %s' % (k, hash(v) )
>               for k, v in kw.items() ]
>    return ' %s:: %s: : %s' % (key, hash_args, hash_kw)
>
> def memoize(get_key=get_key, cache=cache) :
>    def _memoize( function) :
>        print function
>        def __memoize(*args, **kw) :
>            key = get_key(function, *args, **kw)
>            try:
>                return cache[key]
>            except KeyError:
>                cache[key] = function( *args, **kw)
>                return cache[key]
>        return __memoize
>    return _memoize
>
> @memoize()
> def factory(n) :
>    return n * n
>
>
> # testcase
> #print factory(3)
> #
> #
>
>
> According to some of my collogues it is not a good practice to use
> decorators with arguments (i.e. @memoize() ) and instead it is good to
> just use @memoize. Can any of you guys explain me advantages and
> disadvantages of using each of them

Firstly, this really isn't a question for django-developers -- it's
probably not even a question for django-users, since it's a general
Python question, not something that is Django-specific.

Secondly, I have no idea why your colleagues would be advising against
decorators with arguments. They work fine, and examples of decorators
with arguments in Django, in the Python core, and in the PEP where
decorators were introduced into Python as a language. Rejecting them
universally sounds like dogma to me.

The only reason I can think that you might advise against them is in
the case where you aren't (and won't ever) actually using the
arguments -- in that case, there's a minor performance penalty
associated with the extra layer required to support the arguments.
However, that's more a case of 'don't make things more complex than
they need to be', rather than specific advice about decorators.

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.

Re: An idea for a new test method

[Russell Keith-Magee]

On Wed, Jun 29, 2011 at 12:21 AM, Yo-Yo Ma  wrote:
> Problem:
>
> When using the test client, it's simple to check for a 200 response
> code, but not quite as simple to quickly determine, why a 500 was
> encountered, in the case of a test failure.
>
> Proposed Solution:
>
> A new test method which expects a status code of X, and when a 500 is
> encountered instead, the error that caused the 500 is output for ease
> of debugging, such as (one idea for the interface):

I'm a little confused about what you're proposing. The usual case for
receiving a 500 is when a view raises an exception; however, if you're
using the test client, any exceptions raised by the view are re-raised
as exceptions, not handled as 500 errors. This means that whenever a
500 error is raised, you are presented with the full stack trace,
which you can either catch in your test case as an expected failure,
or allow to surface as an error in your test case.

Django's test suite contains examples verifying this exact behavior
(e.g., test_client.ClientTest.test_view_with_exception in modeltests).
This isn't a recent addition, either -- it's been the behavior of the
test client from the beginning.

So - what is the use case you have where this sort of handler would be
necessary?

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.

Re: "c" date formating and Internet usage

[Yohan Boniface]

2011/6/28 Stephen Burrows 

>
> The "O" formatter - or more specifically, the "Z" formatter - does
> include that bit of magic. Is there a particular reason for this?
>

I ask myself the same question. Why for the "Z" (and co) and not for the "c"
?


> Also, if a timezone is assumed, wouldn't it make more sense to assume
> the timezone of the project rather than UTC? Rather than noting an
> inconsistency, can we make this consistent?


Defining the default behaviour when the datetime is naive is not that easy,
in my point of view.

Here is the summary of what I understand (we are talking about the Django's
dateformat util) :

1. when the datetime has a timezone, use it : this is what Django does, and
it's fine.
=> In my point of view, the documentation should be clearer (about the fact
that the "c" formatter, using isoformat, will add the timezone offset only
for non naive datetime and about the fact that this behaviour is not
consistent with other formatters)
=> I'll propose some little patch

2. when the datetime is naive, what to do ?
=> like I said, I think the answer is not that easy, and Django is not
completely coherent on the subject

 2.1 Do nothing
 => this is what Django does for the "c" formatter (as using the .isoformat
datetime method) [1]
 => easier, clearer (no magic), but not so user friendly : it means that
when dealing with naive datetimes, developpers have to manually add the
timezone everytime (error-prone, not very DRY...)

 2.2 Use the system local timezone
 => this is what Django does for the "Z" and "O" formatters for example
(using the time.timezone / .altzone function) [2] [3]
 => basing the default timezone on the machine local one could be risky (and
not so "cloud" aware...)

 2.3 Use the settings.TIME_ZONE information
 => I wonder why this setting is not used by Django here
 => in theory, this sounds like a good default behaviour

 2.4 Missing something ?

And so the final question is : is there a "good" way to arbitrate the
handling of naive datetime when formatting them ?

[1]
https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py
#L126
[2]
https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py
#L269
[3] 
http://docs.python.org/library/time.html
#time.timezone 

-- 
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: using decorators with argument in Python/Django

[Jigar Tanna]

Sorry ... I understand  will be careful may be i put it on a
wrong post ...

On Jun 28, 9:32 pm, Tom Evans  wrote:
> On Tue, Jun 28, 2011 at 5:24 PM, Jigar Tanna  
> wrote:
> > hey,
>
> > I am new to Python and Django, was going through the concept of decorators
> > where I came across a special case of using arguments with decorators
> > Below is the code for memoization where I was looking at the concept...
>
> > cache = {}
> > def get_key(function, *args, **kw) :
> >     key = '%s. %s: ' % (function. __module__,function. __name__)
> >     hash_args = [ str(arg) for arg in args]
> >     hash_kw = [' %s: %s' % (k, hash(v) )
> >    for k, v in kw.items() ]
> >     return ' %s:: %s: : %s' % (key, hash_args, hash_kw)
>
> > def memoize(get_key=get_key, cache=cache) :
> >     def _memoize( function) :
> >     print function
> >     def __memoize(*args, **kw) :
> >     key = get_key(function, *args, **kw)
> >     try:
> >     return cache[key]
> >     except KeyError:
> >     cache[key] = function( *args, **kw)
> >     return cache[key]
> >     return __memoize
> >     return _memoize
>
> > @memoize()
> > def factory(n) :
> >     return n * n
>
> > # testcase
> > #print factory(3)
> > #
> > #
>
> > According to some of my collogues it is not a good practice to use
> > decorators with arguments (i.e. @memoize() ) and instead it is good to just
> > use @memoize. Can any of you guys explain me advantages and disadvantages of
> > using each of them
>
> > Thanks ...
>
> Not to rain too heavily on your parade, but:
>
> 1) Usage questions on django go to django-users@
> 2) Usage questions on python go to comp.lang.python
> 3) Only use django-developers@ if you intend on changing how django
> itself is implemented.
> 4) Submitting the same question twice in such a short time to the same
> mailing list is considered rude.
>
> This doesn't even look like the django.utils.functional.memoize function.
>
> Cheers
>
> Tom

-- 
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: using decorators with argument in Python/Django

[Tom Evans]

On Tue, Jun 28, 2011 at 5:24 PM, Jigar Tanna  wrote:
> hey,
>
> I am new to Python and Django, was going through the concept of decorators
> where I came across a special case of using arguments with decorators
> Below is the code for memoization where I was looking at the concept...
>
> cache = {}
> def get_key(function, *args, **kw) :
>     key = '%s. %s: ' % (function. __module__,function. __name__)
>     hash_args = [ str(arg) for arg in args]
>     hash_kw = [' %s: %s' % (k, hash(v) )
>    for k, v in kw.items() ]
>     return ' %s:: %s: : %s' % (key, hash_args, hash_kw)
>
> def memoize(get_key=get_key, cache=cache) :
>     def _memoize( function) :
>     print function
>     def __memoize(*args, **kw) :
>     key = get_key(function, *args, **kw)
>     try:
>     return cache[key]
>     except KeyError:
>     cache[key] = function( *args, **kw)
>     return cache[key]
>     return __memoize
>     return _memoize
>
> @memoize()
> def factory(n) :
>     return n * n
>
>
> # testcase
> #print factory(3)
> #
> #
>
>
> According to some of my collogues it is not a good practice to use
> decorators with arguments (i.e. @memoize() ) and instead it is good to just
> use @memoize. Can any of you guys explain me advantages and disadvantages of
> using each of them
>
> Thanks ...
>

Not to rain too heavily on your parade, but:

1) Usage questions on django go to django-users@
2) Usage questions on python go to comp.lang.python
3) Only use django-developers@ if you intend on changing how django
itself is implemented.
4) Submitting the same question twice in such a short time to the same
mailing list is considered rude.

This doesn't even look like the django.utils.functional.memoize function.

Cheers

Tom

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

using decorators with argument in Python/Django

[Jigar Tanna]

hey,

I am new to Python and Django, was going through the concept of decorators 
where I came across a special case of using arguments with decorators 
Below is the code for memoization where I was looking at the concept...

cache = {}
def get_key(function, *args, **kw) :
key = '%s. %s: ' % (function. __module__,function. __name__)
hash_args = [ str(arg) for arg in args]
hash_kw = [' %s: %s' % (k, hash(v) )
   for k, v in kw.items() ]
return ' %s:: %s: : %s' % (key, hash_args, hash_kw)

def memoize(get_key=get_key, cache=cache) :
def _memoize( function) :
print function
def __memoize(*args, **kw) :
key = get_key(function, *args, **kw)
try:
return cache[key]
except KeyError:
cache[key] = function( *args, **kw)
return cache[key]
return __memoize
return _memoize

@memoize()
def factory(n) :
return n * n


# testcase 
#print factory(3)
#
#


According to some of my collogues it is not a good practice to use 
decorators with arguments (i.e. @memoize() ) and instead it is good to just 
use @memoize. Can any of you guys explain me advantages and disadvantages of 
using each of them

Thanks ...

-- 
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/-/Exx8QB8-oIIJ.
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.

Python/Django decorators with arguments

[Jigar Tanna]

hey,

I am new to Python and Django, was going through the concept of
decorators where I came across a special case of using arguments with
decorators
Below is the code for memoization where I was looking at the
concept...

cache = {}
def get_key(function, *args, **kw) :
key = '%s. %s: ' % (function. __module__,function. __name__)
hash_args = [ str(arg) for arg in args]
hash_kw = [' %s: %s' % (k, hash(v) )
   for k, v in kw.items() ]
return ' %s:: %s: : %s' % (key, hash_args, hash_kw)

def memoize(get_key=get_key, cache=cache) :
def _memoize( function) :
print function
def __memoize(*args, **kw) :
key = get_key(function, *args, **kw)
try:
return cache[key]
except KeyError:
cache[key] = function( *args, **kw)
return cache[key]
return __memoize
return _memoize

@memoize()
def factory(n) :
return n * n


# testcase
#print factory(3)
#
#


According to some of my collogues it is not a good practice to use
decorators with arguments (i.e. @memoize() ) and instead it is good to
just use @memoize. Can any of you guys explain me advantages and
disadvantages of using each of them

Thanks ...

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

An idea for a new test method

[Yo-Yo Ma]

Problem:

When using the test client, it's simple to check for a 200 response
code, but not quite as simple to quickly determine, why a 500 was
encountered, in the case of a test failure.

Proposed Solution:

A new test method which expects a status code of X, and when a 500 is
encountered instead, the error that caused the 500 is output for ease
of debugging, such as (one idea for the interface):

class FooTestCase(TestCase):
def test_foo(self):
response = self.client.get('/foo/2/')
self.assertStatusCode(foo_response, 302)  # Default could be
200, in practice


When an error response is encountered by the above test could be,
roughly:


F
==
FAIL: test_foo (example.foo.tests.FooTestCase)
--
Traceback (most recent call last):
  File "/example/foo/tests.py", line 8, in test_foo
self.assertStatusCode(foo_response, 302)
AssertionError: 302 != 500

Client response error:

[ERROR THAT CAUSED 500 OR FULL TRACEBACK GOES HERE]


^^ That is, by no means, *the* way to output the information or *the*
best name for the test method,  just my way of conveying the idea.

I don't know how best to achieve this, aside from the obvious, non-
magic version, which would be some regex to parse the response
content. I haven't even looked into the matter, from a low-level
standpoint, and won't unless there is a consensus on what this should
look like, as well as a mutual desire to add this new method.

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[Marco Paolini]

Karen Tracey ha scritto:
On Tue, Jun 28, 2011 at 8:44 AM, Jim Dalton > wrote:




I have not had time to try out the patch, but did look at it.
Doesn't the base implementation of disable_foreign_key_checks
need to return False instead of just passing? The return value is
used in loaddata processing to decide whether it's necessary to
re-enable/check.


It actually doesn't *need* to return False; pass is the same as
not returning anything or returning None. The boolean check just
treats it the same way as False. "Should it?" is another question.
On the one hand it's a bit more clear, this value is called and
always returns False, unless a backend has overridden it. On the
other hand, pass is in keeping with other methods in that class
that are meant to be overridden in backends, so I went with pass
to emphasize that aspect of the code.


Hmm, well, I did not know that falling off the end of a method with 
pass guaranteed a return value of False or None (and can't find that 
noted in the doc here: 
http://docs.python.org/tutorial/controlflow.html#pass-statements) so 
in my mind explicitly returning False would be clearer/better...

a bit off-topic, but...

if no "return" statement is reached, the function will return None. See 
"None" paragraph in [1]


[1] 
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy


Marco

--
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: Timezone-aware storage of DateTime

[Michael Blume]

This seems like probably the correct solution to me. I'd like to suggest
that the time itself still be stored in UTC so that reading the timezone
field is (somewhat) optional
On Jun 28, 2011 8:01 AM, "Sam Bull"  wrote:
> I figured that for most cases you wouldn't actually care what the timezone
was. You would either always be displaying things in a timezone relative to
the user, or you'd use some other external information (ex. coordinates of
person or thing attached to the datetime object) to derive a contextually
appropriate timezone.
>
> For cases where you do want to retain the timezone, how about allowing the
TZ-aware DateTime field to store the TZ data to an optional secondary field?
That field could be a regular CharField. It wouldn't be needed for any of
the date-based sorting or filtering. There's precedent for this sort of
behaviour with the GenericForeignKey, and I think it would be fine,
especially if the secondary field was optional.
>
> What do you think?
>
> Sam
>
> On 2011-06-28, at 9:26 AM, Stephen Burrows wrote:
>
>> I agree that it would be nice to be able to store tz-aware datetimes -
>> but if django were going to do so, it ought to store the datetimes
>> with the timezone information intact, rather than converting
>> everything to the project's timezone. So, if a conversion to UTC were
>> to take place, there would need to be a separate field in the database
>> to store the timezone.
>>
>> On Jun 27, 3:12 pm, Sam Bull  wrote:
>>> On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:
>>>
 Django actually already adds support for some capabilities to certain
 database backends, if I'm not mistaken - such as cascades through GFKs
 on delete.
>>>
 In terms of time zones, could django "assume"/ensure that the datetime
 stored in the backend is UTC, then handle the conversion to the local
 timezone itself?
>>>
>>> Isn't this a viable solution? It's the universal,
cross-timezone-friendly datetime objects that we care about, not the
timezones they were in, right?
>>>
>>> - If the DB supports timezone-aware datetime fields, just pass the
datetime object through as is.
>>>
>>> - If the DB doesn't support timezone-aware datetime fields, convert to
UTC and store the datetime as UTC
>>>
>>> - If the datetime has tz info, convert the time to UTC using that
>>>
>>> - If the datetime doesn't have tz info, convert using the default
timezone specified in the settings
>>>
>>> When retrieving the data from a non-timezone-aware db, convert them from
UTC to the project's timezone.
>>>
>>> Sam
>>
>> --
>> 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.
>>
>
> --
> 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.
>

-- 
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: Timezone-aware storage of DateTime

[Sam Bull]

I figured that for most cases you wouldn't actually care what the timezone was. 
You would either always be displaying things in a timezone relative to the 
user, or you'd use some other external information (ex. coordinates of person 
or thing attached to the datetime object) to derive a contextually appropriate 
timezone.

For cases where you do want to retain the timezone, how about allowing the 
TZ-aware DateTime field to store the TZ data to an optional secondary field? 
That field could be a regular CharField. It wouldn't be needed for any of the 
date-based sorting or filtering. There's precedent for this sort of behaviour 
with the GenericForeignKey, and I think it would be fine, especially if the 
secondary field was optional.

What do you think?

Sam

On 2011-06-28, at 9:26 AM, Stephen Burrows wrote:

> I agree that it would be nice to be able to store tz-aware datetimes -
> but if django were going to do so, it ought to store the datetimes
> with the timezone information intact, rather than converting
> everything to the project's timezone. So, if a conversion to UTC were
> to take place, there would need to be a separate field in the database
> to store the timezone.
> 
> On Jun 27, 3:12 pm, Sam Bull  wrote:
>> On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:
>> 
>>> Django actually already adds support for some capabilities to certain
>>> database backends, if I'm not mistaken - such as cascades through GFKs
>>> on delete.
>> 
>>> In terms of time zones, could django "assume"/ensure that the datetime
>>> stored in the backend is UTC, then handle the conversion to the local
>>> timezone itself?
>> 
>> Isn't this a viable solution? It's the universal, cross-timezone-friendly 
>> datetime objects that we care about, not the timezones they were in, right?
>> 
>> - If the DB supports timezone-aware datetime fields, just pass the datetime 
>> object through as is.
>> 
>> - If the DB doesn't support timezone-aware datetime fields, convert to UTC 
>> and store the datetime as UTC
>> 
>>   - If the datetime has tz info, convert the time to UTC using that
>> 
>>   - If the datetime doesn't have tz info, convert using the default timezone 
>> specified in the settings
>> 
>> When retrieving the data from a non-timezone-aware db, convert them from UTC 
>> to the project's timezone.
>> 
>> Sam
> 
> -- 
> 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.
> 

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[akaariai]

On Jun 28, 12:24 am, "Jim D."  wrote:
> I spent some time last week and over the weekend nailing down a
> solution forhttps://code.djangoproject.com/ticket/3615. This is the
> ticket about allowing forward references when loading data on the
> MySQL InnoDB backend. My patch implements the proposed change
> (disabling foreign key checks when the data is loaded) as well as a
> straightforward SQL SELECT check for integrity after the data is
> loaded, which if I understand it is the missing piece that has
> prevented this ticket from moving forward for the last 4 years...

This is probably not concurrency-safe if the tables are not locked for
the duration of the fixture loading. I don't know if this will ever be
used in situations where concurrency is an issue. Test fixture loading
is certainly not a problematic use-case.

 - 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: Conditional aggregations.

[Javier Guerra Giraldez]

On Tue, Jun 28, 2011 at 9:26 AM, akaariai  wrote:
>> this looks quite non-portable
>
> How? The CASE statement is specified in SQL standard, and it is
> implemented in all database I have used.

i might be totally wrong (wouldn't be first time..) but i've found
myself having to adapt to local dialects almost every time i see some
SQL inside a function, especially on mysql and sqlite.   maybe it's
because of the bad quality of code i tend to see (typically
originating from hand-coded mssql accesses deep within an excel
sheet), but seeing CASE also rings my "i'll need an extra week just
for this" alarm.

then again, i'm s far from being an SQL portability expert.  it's
just something i've (reluctantly) done a few times

-- 
Javier

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[Andy Dustman]

On Mon, Jun 27, 2011 at 6:08 PM, Jacob Kaplan-Moss  wrote:
> On Mon, Jun 27, 2011 at 4:24 PM, Jim D.  wrote:
>> I spent some time last week and over the weekend nailing down a
>> solution for https://code.djangoproject.com/ticket/3615 . This is the
>> ticket about allowing forward references when loading data on the
>> MySQL InnoDB backend. My patch implements the proposed change
>> (disabling foreign key checks when the data is loaded) as well as a
>> straightforward SQL SELECT check for integrity after the data is
>> loaded, which if I understand it is the missing piece that has
>> prevented this ticket from moving forward for the last 4 years...
>
> Interesting approach -- I wouldn't have thought of this! It feels a
> bit nasty to me, but it's rather close to how deferred constraints
> work behind the scenes anyway. I'd like to see some feedback from
> other people who're experienced with MySQL; I don't know enough about
> any potential downsides to spot 'em. But I think you've found a way to
> cut the knot of this problem, and barring a better solution I'd like
> to check this one in.

Disabling foreign key checks is exactly what mysqldump puts at the
start of the dump. Presumably your database will have no bad
references to start with, so the resulting dump shouldn't have any
either, and thus be safe to load with foreign key checks off.

http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html
(for reference)
-- 
Question the answers

-- 
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: Conditional aggregations.

[akaariai]

On Jun 28, 5:18 pm, Javier Guerra Giraldez  wrote:
> On Tue, Jun 28, 2011 at 8:41 AM, akaariai  wrote:
> > This should translate to the following SQL:
> > SELECT sum(case when house.price > 41000 and house.price < 43000 then
> > 1 else 0 end) as expensive_house,
> >       sum(case when house.price > 43000 then 1 else 0 end) as
> > really_expensive_house, ...
> >  FROM house
> >  JOIN something on something.id = house.something_id
>
> this looks quite non-portable

How? The CASE statement is specified in SQL standard, and it is
implemented in all database I have used.

 - 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: Admin inlines and fieldsets

[Stephen Burrows]

Hey,
I reopened the ticket and suggested a syntax that would make more
sense to me than the options already presented there.
Best,
Stephen

On Jun 27, 10:00 am, Russell Keith-Magee 
wrote:
> On Mon, Jun 20, 2011 at 7:51 PM, Aymeric Augustin
>
>
>
>
>
>
>
>
>
>  wrote:
> > Hello,
> > Ticket #10938 [1] suggests declaring inlines in fieldsets, and was closed as
> > wontfix.
> > I think this ticket mixes two different things:
> >     (1) make it possible to *declare* inlines in
> > ModelAdmin.fieldsets instead of ModelAdmin.inlines. This is a bad idea:
> > there should be only one way to declare inlines, and the current way is OK.
> >     (2) make it possible to *include* inlines in ModelAdmin.fieldsets (with
> > a syntax that's still to be defined) in order to chose the position of the
> > inlines in the change form. I think it's useful; actually, I need that right
> > now.
> > Currently, inlines are added at the bottom of the change form — see
> > templates/admin/change_form.html — and displaying them in another position
> > involves re-ordering things with javascript or overriding the change form
> > template. It would be easier if fieldsests accepted both fields and inlines
> > in fieldsets.
> > Reading Russell's closing comment, it looks like he had (1) in mind but not
> > (2). Does the wontfix also apply to (2)?
>
> Hi Aymeric,
>
> Apologies for taking a while to get back to you on this.
>
> You're correct -- I had (1) in mind when I wontfixed the ticket.
> However, I can certainly see the merit in interpretation (2) providing
> a way to include inlines in fieldsets as an organizational/ordering
> mechanism. This general feature request (i.e., ordering of inlines
> within normal field organization) is something that has been proposed
> several times in the past -- in fact, I'd be surprised if there isn't
> a couple of tickets relating to this.
>
> Of course, the devil is in the details -- especially, in finding a
> good syntax given that there isn't a name or label currently available
> for referencing inlines...
>
> 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.

Re: Conditional aggregations.

[Javier Guerra Giraldez]

On Tue, Jun 28, 2011 at 8:41 AM, akaariai  wrote:
> This should translate to the following SQL:
> SELECT sum(case when house.price > 41000 and house.price < 43000 then
> 1 else 0 end) as expensive_house,
>       sum(case when house.price > 43000 then 1 else 0 end) as
> really_expensive_house, ...
>  FROM house
>  JOIN something on something.id = house.something_id

this looks quite non-portable

-- 
Javier

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[Karen Tracey]

On Tue, Jun 28, 2011 at 9:38 AM, Jim Dalton  wrote:

> "In fact, even functions without a return statement do return a value,
> albeit a rather boring one. This value is called None (it’s a built-in
> name). Writing the value None is normally suppressed by the interpreter if
> it would be the only value written."


I guess I did know that at some point, but many many years of writing C code
instilled a lot of caution about falling off the end of functions without
explicitly returning something. C is not so forgiving as to guarantee a
specific value in such cases. Even though Python guarantees it, I think
explicit in these cases is better. But that could just be due to my
background.

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: "c" date formating and Internet usage

[Stephen Burrows]

I realize I may have been a little unclear. I assumed that this
problem was surfacing with relation to datetime fields on models,
which are inherently naive. (For example, an attempt to render a blog
entry's pubdate.) If the "c" formatting option were used in
conjunction with a timezone-aware datetime, then the UTC offset would
appear.

So I'm not saying that "Django doesn't support timezone-aware
datetimes". Django passes *all* of the work for the "c" formatting
option to python's datetime.isoformat() method, which *does* support
them. Sure, we could add some sort of magic that handles naive
datetimes, but I would argue against that on the principle that the
whole reason the datetimes are naive is that one doesn't know what
time zone they're from.

The "O" formatter - or more specifically, the "Z" formatter - does
include that bit of magic. Is there a particular reason for this?
Also, if a timezone is assumed, wouldn't it make more sense to assume
the timezone of the project rather than UTC? Rather than noting an
inconsistency, can we make this consistent?

On Jun 28, 5:47 am, Yohan Boniface  wrote:
> Hi Stephen, Hi Ian, Hi all,
>
> As you say Stephen, isoformat is handling the timezone offset for non naive
> datetime, and so does Django in the "c" date formatter. And I should have
> noticed and mentionned this in my previous email.
> I'll take the time to give a better look to this issue, with these new
> elements.
> By the way, I wonder why for the "O" formatter a workaround is used when the
> datetime is naive, and not for the "c" formatter.
> Anyway, I think that at least a little patch to the doc to clarify the "c"
> behaviour should be useful (naive and non naive datetime). And maybe to warn
> about the non consistent behaviour of Django depending on the date formater
> used.
>
> Yohan
>
> 2011/6/27 Ian Clelland 
>
>
>
>
>
>
>
> > On Sun, Jun 26, 2011 at 12:27 AM, Stephen Burrows <
> > stephen.r.burr...@gmail.com> wrote:
>
> >> This is related to the recent discussion about timezone-aware datetime
> >> storage [1] and how django doesn't do it. Since the date filter's "c"
> >> argument is handled with python's datetime.isoformat() [2] timezone-
> >> naive datetimes will not display a UTC offset.
>
> >> [1]
> >>http://groups.google.com/group/django-developers/browse_thread/thread...
>
> >> [2]
> >>http://docs.python.org/library/datetime.html#datetime.datetime.isoformat
>
> > This isn't the same issue at all -- It may be related, but that discussion
> > thread was about storing timezone-aware timestamps in the database, not
> > about handling them in templates.
>
> > We can't simply say that "Django doesn't support
> > timezone-aware datetimes" -- besides being a ridiculous restriction, it's
> > not true: even in django.utils.dateformat there are several formatting codes
> > that take the input's timezone into account (see I, o, T, U).
>
> > Even the "r" formatting code, for RFC 822 formatting, takes the timezone,
> > if present, into account.
>
> > While I would use the documented claim of PHP compatibility as an argument
> > for this, it's not really a strong argument (and I wouldn't support just
> > removing the claim as a simple solution). A better argument is that the ISO
> > standard allows the timezone, various Internet standards and drafts
> > recommend or require it, and in many cases, it is available to Django, and
> > so we should include it when we can.
>
> > I generally find myself having to introduce a "proper" ISO-8601 formatting
> > string into every project, or supplement the time rendering with a
> > hard-coded timezone, when I can know it for sure (e.g., {{
> > timestamp|date:"c" }}+00:00 ). I would absolutely support adding a "real"
> > ISO-8601 formatter to the standard filter library.
>
> > --
> > Regards,
> > Ian Clelland
> > 
>
> > --
> > 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.

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[Cal Leeming [Simplicity Media Ltd]]

Ah, that makes perfect sense now. It's the same principle when doing a .sql
import, you disable foreign_key_checks, import, then enable.

Thanks for explaining this!

Cal

On Tue, Jun 28, 2011 at 2:41 PM, Jim Dalton  wrote:

> On Jun 28, 2011, at 6:29 AM, Cal Leeming [Simplicity Media Ltd] wrote:
>
> > Sorry for the noobish question but, could someone explain the definition
> of "forward references"?? Is this a MySQL or a django term?? Google wasn't
> very forthcoming :X
>
> Jacob actually requested that I add a note in the database docs on the
> topic this patch addresses. So as a way of answering your question I'll
> paste that note verbatim here:
>
> In previous versions of Django, fixtures with forward references (i.e.
> relations to rows that have not yet been inserted into the database) would
> fail
> to load when using the InnoDB storage engine. This was due to the fact that
> InnoDB
> deviates from the SQL standard by checking foreign key constraints
> immediately
> instead of deferring the check until the transaction is committed. This
> problem has been resolved in Django 1.4. Fixture data is now loaded with
> foreign key
> checks turned off; foreign key checks are then re-enabled when the data has
> finished loading, at which point the entire table is checked for invalid
> foreign
> key references and an `IntegrityError` is raised if any are found.
>
> Is that note illuminating to you? If not, then presumably it needs work :)
>
> --
> 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.
>
>

-- 
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: Conditional aggregations.

[akaariai]

On Jun 27, 4:54 pm, Russell Keith-Magee 
wrote:
> > queryset.aggregate(
> >    expensive_house=Count(house__price,
> > only=(Q(house__price__gt=41000), Q(house__price__lt=43000))),
> >    ...
> >    )
>
> Ok, so that's you're syntax proposal. Now show me the SQL that this
> translates into. In particular, keep in mind that you're doing joins
> in your Q clauses -- how does that get rolled out into SQL?

This should translate to the following SQL:
SELECT sum(case when house.price > 41000 and house.price < 43000 then
1 else 0 end) as expensive_house,
   sum(case when house.price > 43000 then 1 else 0 end) as
really_expensive_house, ...
  FROM house
  JOIN something on something.id = house.something_id
-- The given example queryset is clearly missing that something :)

I think it might be good to restrict the only clauses to the fields of
the same model the aggregated field is in. This way there is already a
usable join generated by the aggregate. The only clause affects the
"case when" structure only.

The only clauses should never restrict the queryset. It gets really
complicated to do that restriction when you have multiple aggregates
using only. You can use filter to restrict the queryset instead. And
you probably don't want the filter there in any case, In the above
example, you would not get any results for the rows aggregating to 0.

If the only clauses never restrict the queryset, then translating
conditional aggregates to SQL isn't really _that_ complicated. When
you normally generate "avg(table.column) as column_avg", now you just
generate "avg(case when table.some_column matches only condition then
table.column else null end)" as column_avg.

 - 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: Thoughts on solution to forward references in MySQL (#3615)

[Jim Dalton]

On Jun 28, 2011, at 6:29 AM, Cal Leeming [Simplicity Media Ltd] wrote:

> Sorry for the noobish question but, could someone explain the definition of 
> "forward references"?? Is this a MySQL or a django term?? Google wasn't very 
> forthcoming :X

Jacob actually requested that I add a note in the database docs on the topic 
this patch addresses. So as a way of answering your question I'll paste that 
note verbatim here:

In previous versions of Django, fixtures with forward references (i.e.
relations to rows that have not yet been inserted into the database) would fail
to load when using the InnoDB storage engine. This was due to the fact that 
InnoDB
deviates from the SQL standard by checking foreign key constraints immediately
instead of deferring the check until the transaction is committed. This
problem has been resolved in Django 1.4. Fixture data is now loaded with 
foreign key
checks turned off; foreign key checks are then re-enabled when the data has
finished loading, at which point the entire table is checked for invalid foreign
key references and an `IntegrityError` is raised if any are found.

Is that note illuminating to you? If not, then presumably it needs work :)

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[Jim Dalton]

On Jun 28, 2011, at 6:25 AM, Karen Tracey wrote:

> It actually doesn't *need* to return False; pass is the same as not returning 
> anything or returning None. The boolean check just treats it the same way as 
> False. "Should it?" is another question. On the one hand it's a bit more 
> clear, this value is called and always returns False, unless a backend has 
> overridden it. On the other hand, pass is in keeping with other methods in 
> that class that are meant to be overridden in backends, so I went with pass 
> to emphasize that aspect of the code.
> 
> Hmm, well, I did not know that falling off the end of a method with pass 
> guaranteed a return value of False or None (and can't find that noted in the 
> doc here:http://docs.python.org/tutorial/controlflow.html#pass-statements) so 
> in my mind explicitly returning False would be clearer/better...

Ah, okay. To be clear, the return value actually has nothing to do specifically 
with the use of pass or not. The behavior of Python is to return None from any 
function that does not explicitly return a value. This is from the exact same 
page in the Python docs you linked to:

"In fact, even functions without a return statement do return a value, albeit a 
rather boring one. This value is called None (it’s a built-in name). Writing 
the value None is normally suppressed by the interpreter if it would be the 
only value written."

Obviously it's a fairly minor point but we want things to be as clear as 
possible. Anyone else wants to weigh in on "pass" vs. an explicit return value?

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[Cal Leeming [Simplicity Media Ltd]]

Sorry for the noobish question but, could someone explain the definition of
"forward references"?? Is this a MySQL or a django term?? Google wasn't very
forthcoming :X

Thanks

Cal

On Mon, Jun 27, 2011 at 10:24 PM, Jim D.  wrote:

> Hi all,
>
> I spent some time last week and over the weekend nailing down a
> solution for https://code.djangoproject.com/ticket/3615 . This is the
> ticket about allowing forward references when loading data on the
> MySQL InnoDB backend. My patch implements the proposed change
> (disabling foreign key checks when the data is loaded) as well as a
> straightforward SQL SELECT check for integrity after the data is
> loaded, which if I understand it is the missing piece that has
> prevented this ticket from moving forward for the last 4 years...
>
> Anyhow, the patch should be 100% there so I'd love if someone could
> check it out and either push it along or let me know if any changes
> are required. It should be easy enough for me to address any issues
> while the whole problem is in my head.
>
> I'm using django-threadedcomments on a project, which has forward
> references in one of its test fixtures, so I'm reminded of this issue
> every time I run my project tests. I hate test errors! I'm hopeful the
> latest patch is sufficient to get this issue resolved.
>
> Thanks
> Jim
>
> --
> 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.
>
>

-- 
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: Timezone-aware storage of DateTime

[Stephen Burrows]

I agree that it would be nice to be able to store tz-aware datetimes -
but if django were going to do so, it ought to store the datetimes
with the timezone information intact, rather than converting
everything to the project's timezone. So, if a conversion to UTC were
to take place, there would need to be a separate field in the database
to store the timezone.

On Jun 27, 3:12 pm, Sam Bull  wrote:
> On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:
>
> > Django actually already adds support for some capabilities to certain
> > database backends, if I'm not mistaken - such as cascades through GFKs
> > on delete.
>
> > In terms of time zones, could django "assume"/ensure that the datetime
> > stored in the backend is UTC, then handle the conversion to the local
> > timezone itself?
>
> Isn't this a viable solution? It's the universal, cross-timezone-friendly 
> datetime objects that we care about, not the timezones they were in, right?
>
> - If the DB supports timezone-aware datetime fields, just pass the datetime 
> object through as is.
>
> - If the DB doesn't support timezone-aware datetime fields, convert to UTC 
> and store the datetime as UTC
>
>   - If the datetime has tz info, convert the time to UTC using that
>
>   - If the datetime doesn't have tz info, convert using the default timezone 
> specified in the settings
>
> When retrieving the data from a non-timezone-aware db, convert them from UTC 
> to the project's timezone.
>
> Sam

-- 
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: Thoughts on solution to forward references in MySQL (#3615)

[Karen Tracey]

On Tue, Jun 28, 2011 at 8:44 AM, Jim Dalton  wrote:

>
> I have not had time to try out the patch, but did look at it. Doesn't the
> base implementation of disable_foreign_key_checks need to return False
> instead of just passing? The return value is used in loaddata processing to
> decide whether it's necessary to re-enable/check.
>
>
> It actually doesn't *need* to return False; pass is the same as not
> returning anything or returning None. The boolean check just treats it the
> same way as False. "Should it?" is another question. On the one hand it's a
> bit more clear, this value is called and always returns False, unless a
> backend has overridden it. On the other hand, pass is in keeping with other
> methods in that class that are meant to be overridden in backends, so I went
> with pass to emphasize that aspect of the code.
>

Hmm, well, I did not know that falling off the end of a method with pass
guaranteed a return value of False or None (and can't find that noted in the
doc here: http://docs.python.org/tutorial/controlflow.html#pass-statements)
so in my mind explicitly returning False would be clearer/better...

Cheers,
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: Thoughts on solution to forward references in MySQL (#3615)

[Jim Dalton]

On Jun 28, 2011, at 5:27 AM, Karen Tracey wrote:

> Also, though I don't have MySQL 4 handy to test on, I'd be astonished if 
> there were any issue there compared to MySQL 5. The set foreign_key_check 
> command is certainly supported in MySLQ 4 and the select being issued to do 
> the check is nothing special at all. 

Agreed. I did find some circumstantial evidence to support the idea that ti 
would work on MySQL 4 here: 
http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html#c3009
 This comment from 2003 (when MySQL 4 was still in beta) described the 
technique. If it worked in 2003 I have to imagine we're in good shape.

Slightly higher concern is the new get_key_relations() method. Since the 
information_schema table is not available before MySQL 5 there is a workaround 
in there for version 4. The contents of this method were originally part of 
get_indexes() and I just moved them to their own method (that's why you don't 
see it in the commit). So assuming that function worked fine previously in 
Django, I don't anticipate this will have a problem either.

> 
> I have not had time to try out the patch, but did look at it. Doesn't the 
> base implementation of disable_foreign_key_checks need to return False 
> instead of just passing? The return value is used in loaddata processing to 
> decide whether it's necessary to re-enable/check.

It actually doesn't *need* to return False; pass is the same as not returning 
anything or returning None. The boolean check just treats it the same way as 
False. "Should it?" is another question. On the one hand it's a bit more clear, 
this value is called and always returns False, unless a backend has overridden 
it. On the other hand, pass is in keeping with other methods in that class that 
are meant to be overridden in backends, so I went with pass to emphasize that 
aspect of the code.

> 
> Thanks for working on this -- wish I'd thought of that idea two years ago!

You're welcome. It was actually fun to solve a cold case :)

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

Form media, expose raw urls to templates

[crodjer]

The form media widget should also allow an access to the direct javascript
urls (Instead of just rendering it directly) so that it can be used with 
javascript
loaders (I perticularly use headjs  which supports 
parallel loading of javascripts.
But for using it I always have to write custom form methods as accessing 
private
variables (._js) is reastricted. 

I finally set about and added few lines to the form media widget. The patch:
https://github.com/crodjer/django/commit/8fa41950bcfe1396862a17dc5e138af35075005a

I think that django should allow an access to the media (at least js) as the 
html
rendring required is not always the way the form does.

If there is a simpler way to achieve this, please suggest.

-- 
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/-/2Pck_o-u7o0J.
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: Thoughts on solution to forward references in MySQL (#3615)

[Karen Tracey]

On Mon, Jun 27, 2011 at 11:26 PM, Jim D.  wrote:

> My thinking at this point would be the performance is "good enough" for the
> scope of the current ticket, and that if better performance were required or
> desired, that could be facilitated under a separate ticket, assuming there
> was community demand for it.


I agree. I tried that select with a ~1.5 million row referring table
crossing tables with ~150,000 and ~17,000 row tables and they completed in
less than a second. I think fixing this issue on this backend is well worth
adding possibly several seconds to loaddata time there.

Also, though I don't have MySQL 4 handy to test on, I'd be astonished if
there were any issue there compared to MySQL 5. The set foreign_key_check
command is certainly supported in MySLQ 4 and the select being issued to do
the check is nothing special at all.

I have not had time to try out the patch, but did look at it. Doesn't the
base implementation of disable_foreign_key_checks need to return False
instead of just passing? The return value is used in loaddata processing to
decide whether it's necessary to re-enable/check.

Thanks for working on this -- wish I'd thought of that idea two years ago!

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: Odp: Re: Odp: Re: Storing language in session/cookie

[Mikoskay]

Yes, but obviously this is not going to be the blessed, default behavior.

--
Mikołaj Siedlarek


On Mon, Jun 27, 2011 at 3:15 PM, Max Arnold  wrote:

> Another approach is to store language in the url (useful for mobile
> handsets where disabled or unsupported cookies is still an issue).  Django
> app which uses this method: https://bitbucket.org/carljm/django-localeurl
>
> --
> 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/-/KD9VoA6u6sEJ.
> 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.
>

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Chris,

2011/6/27 Chris Beaven :
> How do I override a field's label or help text?
> Specifically, help text may need to look something like: [[Can this person
> manage {{
> site.name }}?]]

This isn't addressed with the proposed template tags. You can still write out
a single row by hand if you need to tweak it in the low level details. I know
this is not ideal and exactly what we want to avoid with the new rendering.
Because of this I will try to design the code that spits out the form in the
end to be very modular. Basically it should be possible in the end to have
your own "formconfig" template tags that change the rendering a bit, like
changing a label or the help text (label is also my sample usecase).

However I think these templatetags could go into a thirdparty app. First
reason is to show-case that thirdparty rendering modifications are possible,
second to not clutter the builtin tags with too many possibilities. I would
like more to provide a framework for rendering, than all the tiny details you
propably could plugin into it your self.

BTW: even without the thirdparty apps it's already possible to change the
label for a field in an (somehow) easy way. Just extend from the row template
you use for your other rows in the form and override the {% block label %}.

Another option is to have something like this in your row template:

{% firstof label field.label %}

label is usually not in the row's scope so field.label is choosen. Now you can
modify the label with:

{% formrow myform.field with label="My new label" %}

> How are HTML classes specified for rows which are required / contain errors?
> (and one more slightly obscure one, probably out of scope...)

This can be achieved in the row template:



> How does a row know whether it contains HTML block elements?
> For example, a "p" row needs to render differently if it contains HTML block
> elements, such as a field represented as an unordered list of checkboxes.

This is not addressed, and I have no clue how we should do this -- or if we
should do this at all :o)

2011/6/27 Chris Beaven :
> Oh, and one more critical one:
> How does the form in python have knowledge of the widget which the field was
> rendered with as picked by the template?
> This is critical since building the form's data requires using the widget's
> value_from_datadict.

I think thats conceptually not possible. We simply can change the widget during
template rendering time, which makes it impossible to decide in the python
code with which widget we end up. And theoretically we could even render the
form twice with different widgets. Or throw the rendered template away without
using the widget at all.

So I think we must make clear that the used widgets must be somehow
compatible. I agree that we need to document this in one or the other way.

--
Servus,
Gregor Müllegger

-- 
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: Django Design Czar

[Kenneth Gonsalves]

On Mon, 2011-06-27 at 00:10 -0700, Victor Hooi wrote:
> Was somebody made the Django design czar? 

yes - Idan Gazit
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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: "c" date formating and Internet usage

[Yohan Boniface]

Hi Stephen, Hi Ian, Hi all,

As you say Stephen, isoformat is handling the timezone offset for non naive
datetime, and so does Django in the "c" date formatter. And I should have
noticed and mentionned this in my previous email.
I'll take the time to give a better look to this issue, with these new
elements.
By the way, I wonder why for the "O" formatter a workaround is used when the
datetime is naive, and not for the "c" formatter.
Anyway, I think that at least a little patch to the doc to clarify the "c"
behaviour should be useful (naive and non naive datetime). And maybe to warn
about the non consistent behaviour of Django depending on the date formater
used.

Yohan


2011/6/27 Ian Clelland 

> On Sun, Jun 26, 2011 at 12:27 AM, Stephen Burrows <
> stephen.r.burr...@gmail.com> wrote:
>
>> This is related to the recent discussion about timezone-aware datetime
>> storage [1] and how django doesn't do it. Since the date filter's "c"
>> argument is handled with python's datetime.isoformat() [2] timezone-
>> naive datetimes will not display a UTC offset.
>>
>> [1]
>> http://groups.google.com/group/django-developers/browse_thread/thread/76e2b486d561ab79/0a46b72da6e9fb03
>>
>> [2]
>> http://docs.python.org/library/datetime.html#datetime.datetime.isoformat
>>
>>
> This isn't the same issue at all -- It may be related, but that discussion
> thread was about storing timezone-aware timestamps in the database, not
> about handling them in templates.
>
> We can't simply say that "Django doesn't support
> timezone-aware datetimes" -- besides being a ridiculous restriction, it's
> not true: even in django.utils.dateformat there are several formatting codes
> that take the input's timezone into account (see I, o, T, U).
>
> Even the "r" formatting code, for RFC 822 formatting, takes the timezone,
> if present, into account.
>
> While I would use the documented claim of PHP compatibility as an argument
> for this, it's not really a strong argument (and I wouldn't support just
> removing the claim as a simple solution). A better argument is that the ISO
> standard allows the timezone, various Internet standards and drafts
> recommend or require it, and in many cases, it is available to Django, and
> so we should include it when we can.
>
> I generally find myself having to introduce a "proper" ISO-8601 formatting
> string into every project, or supplement the time rendering with a
> hard-coded timezone, when I can know it for sure (e.g., {{
> timestamp|date:"c" }}+00:00 ). I would absolutely support adding a "real"
> ISO-8601 formatter to the standard filter library.
>
> --
> Regards,
> Ian Clelland
> 
>
> --
> 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.
>

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