Problem UnicodeDecodeError when run createsuperuser

[Lucas Simon Rodrigues Magalhaes]

Hello everyone,

I have a problem when run createsuperuser.py command in python 3.4. How can 
I solve it definitely?

Look the code:

https://gist.github.com/lucassimon/7837dce442e3a4a090ce4d155b4a2035

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fee89dec-a2cf-4fd1-96c3-189647202926%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Custom 400 error handler or capture broken URLs

[Simon Steinberger]

Excellent - thank you!

On Friday, October 10, 2014 4:00:33 PM UTC+2, Karen Tracey wrote:
>
> There is a ticket open on this issue:
>
> https://code.djangoproject.com/ticket/19508
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/04b02c02-3504-4702-9765-4ad51ab83b85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Custom 400 error handler or capture broken URLs

[Simon Steinberger]

Django sites respond to broken URLs with a blank error 400 page. E.g. here 
on Disqus:

http://disqus.com/%C3A4

This error is raised inside the WSGI application and currently there's no 
way to avoid it or to use some custom error 400 page. We do have a nasty 
patch that's grossly inefficient and ugly:

http://stackoverflow.com/questions/14636986/catch-incorrectly-encoded-urls-in-django-to-return-a-custom-error-400-page/14682988#14682988

Would be nice to be able to catch this error in a more Django-friendly way.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/4e1941f9-70f8-4357-b19c-933ddc5adfe3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Simon Riggs]

On 28 September 2014 19:30, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:

> "Obviously the PostgreSQL project can make its own choices. But I'm surprised
> that you're proposing non-standard syntax and semantics, considering
> PostgreSQL's tradition to comply with SQL standards. Even if you disagree with
> some aspects of the specification of MERGE, wouldn't it be valuable to
> implement it properly? Since I'm not the most knowledgeable person on this
> topic, where can I learn more about the reasons for this choice?"

A fair point.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CA%2BU5nM%2BVgfrn6i4C%3DWxbCxr10KsTdWTX%2BZ-89CyCvnY5Gn1F3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Simon Riggs]

On 28 September 2014 14:32, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> On 28 sept. 2014, at 13:44, Petite Abeille <petite.abei...@gmail.com> wrote:
>
>> Again, your house, your choice. But it seems a bit self-indulgent to concoct 
>> your very own take on MERGE, with baroque syntax, peculiar semantic, and 
>> all, just because some abstract aspects of the MERGE specification is not to 
>> you liking... rather self-defeating altogether.
>
> Hello Petite Abeille,
>
> I don't know how much research you have done in this area, but I hope you're 
> at least as knowledgeable as Peter if you're going to talk to him like that.

The reason to post here was to receive opinions from the Django
community, so those comments are welcome.

> You're certainly aware that there have been years of discussions on this very 
> question in the PostgreSQL community. It wasn't easy to come to a decision.

And the Django community's opinions might differ, for valid reasons.

> You're allowed to disagree with that decision, however:
>
> 1) The django-developers mailing list isn't the place to rehash the debate,
> 2) The disparaging vocabulary you're using isn't acceptable in this forum,
> 3) Personal attacks based on prejudice will not be tolerated.

Well, for 1) any comments are most welcome. I didn't see any evidence
of the other two.

All opinions welcome.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CA%2BU5nMLrwDNr6dnfJGtYU7gAgR2a-MgmbsmM%3DCnLGoc%3DWh_hVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Simon Riggs]

On 28 September 2014 00:01, Peter Geoghegan <p...@heroku.com> wrote:

> I am a PostgreSQL major contributor, currently undertaking development
> of a feature sometimes called "UPSERT" for PostgreSQL.

Thanks for posting this Peter.

The feature is under review in the PostgreSQL community and we would
like to solicit open feedback about how such a feature might look and
what aspects make it more/less likely to be adopted by Django.

Detailed feedback on ORM related issues is welcome.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CA%2BU5nMLBnfk7TNZSjeagzYG0bd2E_6nooErbYTx2jXp5R7U6bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: "UPSERT" in PostgreSQL

[Simon Riggs]

On 28 September 2014 02:22, Shai Berger <s...@platonix.com> wrote:

> Upon reading the docs, I was a little surprised to see that in terms of
> triggers etc, the operation is always considered an INSERT. I would expect it
> to be considered an insert for BEFORE INSERT or INSTEAD OF INSERT triggers,
> but if conflict resolution turns it into an UPDATE, I'd expect to see it
> handled as an UPDATE from that point on (definitely INSTEAD OF UPDATE and 
> AFTER
> UPDATE triggers, maybe even BEFORE UPDATE). That is the semantics we have now
> (this is a general remark, not particulary Django-oriented; Django does not
> use triggers on PG as far as I know, and only uses them elsewhere to implement
> serial keys).

Hmm, good thinking.

So it should act like this?

BEFORE INSERT triggers fire
if CONFLICT then
{
  BEFORE UPDATE triggers fire
  perform UPDATE
  AFTER UPDATE triggers fire
}
else
{
  perform INSERT
  AFTER INSERT triggers fire
}

INSTEAD OF triggers would fire on views only, so would be shown in the
above instead of the before triggers

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CA%2BU5nMJbr-b09Ed6AxTeU44TNZF53_NDYc0DuV-RtcQqqQ7u3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Database Constraints

[Simon Blanchard]

Hi

Just FYI: back in 2007 GSOC there was a project to add constraints. The
syntax was as follows:

class Manufacturer(models.Model):
mfg_name = models.CharField(maxlength=50)
car_sale_start = models.DateField()
car_sale_end = models.DateField()
quantity_sold = models.IntegerField()
car_price = models.IntegerField()

class Meta:
constraints = (
("check_name", Check(mfg_name__like = 'Merc*')),
("check_date", Check(car_sale_start__between = [date(2007,1,1),
date(2008,1,1)])),
("check_end_date", Check(car_sale_end__gte = 'car_sale_start')),
("check_quantity", Check(quantity_sold__gte = 0)),
("check_price", Check(car_price__between = [0, 1])),
  )


So a list of constraint name and a Check() pairs. I think the idea was that
Check() could be ANDd or ORd together a bit like the Q() object.

It worked with Postgres AFAIR.

Simon



On Tue, Apr 1, 2014 at 7:07 PM, schinckel <m...@schinckel.net> wrote:

> Some years ago, I discussed adding database-level check constraints into
> django:
> https://groups.google.com/forum/#!topic/django-developers/OJN5kpcseAg
>
> There is also an issue: https://code.djangoproject.com/ticket/11964
>
> I'm thinking about revisiting this, and wanted to get some discussion
> going about if this is a viable thing to do, and what it might look like.
>
>
> Django already uses check constraints with PositiveIntegerField and
> friends, and at first blush I thought we might be able to co-opt some of
> that (indeed, I've got an internal monkey-patch that does, with some level
> of success). However, other than the fact there is already a
> 'sql_create_check' string, the actual python code that creates the check
> constraint probably isn't that usable in this context. Also, I like the
> idea of having more complex constraints (postgres has EXCLUDE constraints,
> but I don't know if there is an equivalent for other backends).
>
>
> The approach that I am thinking of could see a syntax similar to:
>
>
> class MyModel(models.Model):
> start = models.DateField()
> finish = models.DateField(constraints=[('check', '> start')])
> user = models.ForeignKey('auth.User')
>
> This maps directly to creating a check constraint on the table:
>
>  ALTER TABLE "myapp_mymodel" ADD CONSTRAINT CHECK (finish > start)
>
> And, on the same model, a more complex constraint could look like:
>
>
> class Meta:
> constraints = [
> ('exclude', [
> ('overlaps', ['start','finish']),
> ('equal', 'user')
> ])
>]
>
> I'm still unsure of the best way to describe this: it's supposed to mean:
>
>ALTER TABLE "myapp_mymodel" ADD EXCLUDE USING gist
> (daterange(start, finish) WITH &&, user_id WITH =)
>
> (but the python syntax is obviously immaterial at this stage).
>
>
> Obviously, we can't just rely on the database to do the validation for us:
> it will just raise DatabaseErrors when something fails to validate anyway,
> so we would want to handle this stuff in django's validation framework.
>
> One possibility, at least with the field-based check constraint, would be
> to automatically add a field validator in the case of a CHECK constraint,
> however in the case of an EXCLUDE constraint, we can't really validate
> _without_ hitting the database. Does this mean we should treat EXCLUDE-type
> constraints as something that is beyond the scope of Django?
>
>
>
> With the new migrations framework, it's actually trivial to write a
> migration to add this type of constraint (or the check constraint), and a
> pre_save signal handler in conjunction with that would get 90% of the way,
> but it's still going to be open to a race condition anyway - the only way
> to actually do that is to try to save the object and see what the database
> says.
>
>
> So, I guess I'm asking: is it worth pursuing this further, either in part
> or full?
>
> Matt.
>
>  --
> 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/250ed272-198a-478f-b2ce-920afcf533a2%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/250ed272-198a-478f-b2ce-920afcf533a2%40googlegroups.com?utm_medium=email_source=footer>
> .
> For m

Feature request: New middleware method for "universal" decoration

[Simon Percivall]

If this has already been discussed/rejected/accepted, sorry, I did a search 
and found nothing.

There are several snippets and a number of methods to enable "universal" 
decorations of views in Django, but none of them feels really natural. 
Also, being able to keep this class of code in one place makes it easier to 
find.

Basically, what I propose is adding a middleware method, e.g. 
"decorate_view(...)", which returns the view function, decorated or not, or 
completely replaced. This new function would then be used as the "callback" 
before "process_view" is called in django/core/handlers/base.py.

It would enable an easier way to universally, dynamically wrap views with 
for instance context managers, a process which doesn't really exist today: 
To do this with a view middleware would mean not being able to use another 
view middleware, to use process_request & process_response would mean not 
being certain "__exit__" was called.

-- 
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/67ee3167-8030-4946-a24d-580b4724ca0e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Remove contrib redirect's dependency on sites

[Simon Litchfield]

Contrib redirects is still a handy little app, but it's dependency on 
contrib.sites is often unnecessary and a little annoying.

Would anyone else be keen to see the dependency removed, gracefully? If so 
I'll spin up the code.

-- 
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/6bd7adfc-13e6-46f7-aec3-d1b84243e2e9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Simon Kern]

Yes but management commands should be irrelevant for django-secure

Am 15.09.13 17:52, schrieb Aymeric Augustin:
> On 15 sept. 2013, at 16:40, Simon K. <sim...@gmail.com> wrote:
>
>> But in production the entry point is the wsgi.py file, isn't it?
> It's the main entry point in production, but not the only one; manage.py / 
> django-admin.py is still used  to run management commands.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Simon K.]

Am Mittwoch, 17. Juli 2013 10:20:47 UTC+2 schrieb Russell Keith-Magee:
>
>
> On Mon, Jul 15, 2013 at 8:17 PM, Christopher Medrela 
> <chris@gmail.com
> > wrote:
>
>> Progress: I've implemented manager checks.
>>
>> This API allows us to register, among other things, app-specific checks. 
>> But
>> it's not necessary to write an app in order to do some checks.
>>
>> `register` function will have two optional parameters: `run_in_production`
>> (default: False) and `run_in_development` (default: True) that let you 
>> specify
>> when the callable should be called. Most checks should be performed only 
>> in
>> development environment (which is equivalent to DEBUG==True). Security 
>> checks
>> makes sense only in production environment (<==> DEBUG==False).
>>
>> I would be happy if I could hear your opinion!
>>
>
> Hi everyone,

just out of curiosity (excuse me if I am wrong):
Isn't there already a strong determing factor of whether a django project 
is running "in development" or "in production" despite the debug setting? 
In development you would usually use manage.py to invoke your devserver.
But in production the entry point is the wsgi.py file, isn't it?  At least 
this seems to be a more reliable approach for me than the pure 
differentiation based on the state of the debug setting.

Simon

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

[Simon Litchfield]

An improvement for sure. Any reason it can't be a little more pythonic, ie 
using optional kwargs etc?

My only concern is in having two ways of achieving the same thing. If the 
latter is simpler and more flexible, does this place our entire 
ValidationError approach to handling form and model errors in question? 
Hmmm. Maybe we can come back to that later :-/


On Tuesday, 20 August 2013 14:11:44 UTC+10, Loic Bistuer wrote:
>
> There is a ticket with a PR to address the issue of targeting specific 
> fields when raising errors; I'm awaiting feedback on what should be the 
> documented API. 
>
> https://code.djangoproject.com/ticket/20867. 
>
> This patch enables two patterns: 
>
> - Raising ValidationError({'field': 'error'}) from `Form.clean()`. 
>
> - Calling Form.add_errors('field', 'error') from anywhere. 
>
> The former is actually something that existed for a long time; only it 
> couldn't be used from `Form.clean()`. This pattern allows targeting 
> specific fields from the `Model` layer (see #16986). 
>
> The later has been proposed by @akaariai and @mjtamlyn, it's easier to use 
> for the simple cases and it's accessible from outside the form, from a view 
> for example. 
>
> The current patch only documents the dict construct for `ValidationError` 
> since `Form.add_errors` was a private method in my original patch; should 
> both be documented or only `Form.add_errors`? 
>
> -- 
> Loic 
>
> On Aug 20, 2013, at 7:58 AM, Simon Litchfield 
> <litch...@gmail.com> 
> wrote: 
>
> > Lack of clean control over field-specific form errors is an issue that 
> has been raised and discussed many times over the years, but still the 
> solution seems pretty inadequate. We're even directing people hack around 
> with _errors and making excuses for it in the documentation. 
> > 
> https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors
>  
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

ValidationError for fields

[Simon Litchfield]

Lack of clean control over field-specific form errors is an issue that has 
been raised and discussed many times over the years, but still the solution 
seems pretty inadequate. We're even directing people hack around with 
_errors and making excuses for it in the documentation.
https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors

What about an optional kwarg on ValidationError? Eg, raise 
forms.ValidationError('This field is seriously not cool', field='myfield'). 
Current 
behaviour as-is.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecation a little harsh?

[Simon Litchfield]

On Monday, 12 August 2013 17:23:40 UTC+10, Aymeric Augustin wrote:
>
> It would be interesting to describe what actual problems these libraries 
> encountered. Were they caused by actual deprecations or by changes in 
> private APIs? 
>

One example would be simplejson, why not leave a stub there that imports 
json? IMHO that was a little draconian and needlessly broke several third 
party apps.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Deprecation a little harsh?

[Simon Litchfield]

It's great all the housekeeping we've been doing lately, and I'm sure we 
all agree nice to have clean, tidy code; but I wonder if we've been a 
little too unforgiving at the expense of easy compatibility with important 
third party apps?

Celery, sorl-thumbnail, mptt, registration, shorturls, compressor, tinymce 
(I could go on) have been having trouble keeping up. 

One of Django's key strengths is the large collection of apps. Some aren't 
as regularly maintained as we'd like but we still love them. Is it a little 
unreasonable to expect them all to move so fast?

Any one else found themselves spending too much time lately patching other 
peoples' stuff?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Simon Blanchard]

Could you explain why? And why it matters if the user is registered or not?

Alternatively, if the token is present and wrong and it's not a POST, reset
the token.

Thanks


On Thu, Aug 8, 2013 at 11:24 AM, Alex Ogier <alex.og...@gmail.com> wrote:

> That's too hard to enforce. It would mean that you can't show user content
> on any public page, or any page that you want to be accessible from outside
> links. For example, you couldn't show blog comments to unregistered users.
> It would be too disruptive. Modifying the format of the secret token is a
> much better idea -- you only need to obfuscate it enough to defeat the
> compression scheme, not an adversarial attacker.
>
>
> On Wed, Aug 7, 2013 at 3:23 AM, Simon Blanchard <bno...@gmail.com> wrote:
>
>> I think they nibble at it. They look at the compressed length - the
>> shorter the compressed length closer they are. But if an incorrect CSRF was
>> never reflected there would be nothing for them to nibble at. It says this
>> in the paper:  "However, we remark that requiring a valid CSRF token for
>> all requests that reflect user input would defeat the attack."
>>
>>
>>
>> On Wed, Aug 7, 2013 at 3:13 PM, Curtis Maloney <
>> cur...@acommoncreative.com> wrote:
>>
>>> They don't try to guess the CSRF directly, AIUI.
>>>
>>> They use a form field to affect their test.
>>>
>>> The easiest solution I can see is the one mentioned in the document --
>>> instead of outputting the raw value, output SALT || (SALT ^ TOKEN) so the
>>> actual value is never in the response, but it can be retrieved by simply
>>> xoring it with the salt.  The salt is changed every request.
>>>
>>> --
>>> Curtis Maloney
>>>
>>>
>>>
>>> On 7 August 2013 16:56, simonb <bno...@gmail.com> wrote:
>>>
>>>> How about requiring that if csrfmiddlewaretoken is set, no matter what
>>>> http method (GET, POST...), it is correct otherwise 403 response.
>>>>
>>>> Simon
>>>>
>>>>  --
>>>> 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.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>>
>>>
>>>  --
>>> 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.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Improving ForeignKeyRawIdWidget (raw_id_fields in admin)

[Simon Meers]

On 13 June 2013 07:41, Simon Meers <drme...@gmail.com> wrote:

> On 13 June 2013 03:33, <rich...@richard.ward.name> wrote:
>
>> I think that the usability of ForeignKeyRawIdWidget could be vastly
>> improved if the representation part of the widget (the object name, in
>> bold) were to be updated when a new object gets chosen. I think this could
>> be done relatively easily with a small change introducing little extra
>> complexity.
>>
> The handling of raw IDs, particularly in a comma-separated list for
> many-to-many relationships, is arguably the biggest user-facing "wart" in
> the current admin implementation. The sheer number of available related
> objects often makes listing the full set in a dropdown or other widget
> unfeasible, forcing developers to resort to the raw ID mechanism to a)
> improve efficiency in terms of database-querying and response/DOM-size, and
> b) make the selection interface manageable and allow
> searching/filtering/pagination/etc. Providing a textual representation of
> the object as per the standard widgets makes sense here.
>

Julien Phalip has recently put a new patch together for this -- see
https://code.djangoproject.com/ticket/7028#comment:74 -- reviews would be
greatly appreciated.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Simon Blanchard]

I think they nibble at it. They look at the compressed length - the shorter
the compressed length closer they are. But if an incorrect CSRF was never
reflected there would be nothing for them to nibble at. It says this in the
paper:  "However, we remark that requiring a valid CSRF token for all
requests that reflect user input would defeat the attack."


On Wed, Aug 7, 2013 at 3:13 PM, Curtis Maloney
<cur...@acommoncreative.com>wrote:

> They don't try to guess the CSRF directly, AIUI.
>
> They use a form field to affect their test.
>
> The easiest solution I can see is the one mentioned in the document --
> instead of outputting the raw value, output SALT || (SALT ^ TOKEN) so the
> actual value is never in the response, but it can be retrieved by simply
> xoring it with the salt.  The salt is changed every request.
>
> --
> Curtis Maloney
>
>
>
> On 7 August 2013 16:56, simonb <bno...@gmail.com> wrote:
>
>> How about requiring that if csrfmiddlewaretoken is set, no matter what
>> http method (GET, POST...), it is correct otherwise 403 response.
>>
>> Simon
>>
>>  --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Negative Indexing on QuerySets

[Simon Riggs]

On 31 July 2013 07:56, Florian Apolloner <f.apollo...@gmail.com> wrote:
> Hi Wim,
>
>
> On Wednesday, July 31, 2013 12:04:42 AM UTC+2, Wim Lewis wrote:
>>
>> On 30 Jul 2013, at 2:06 PM, Florian Apolloner wrote:
>> > How do you think such support would look like? For negative indices
>> > you'd have to know the size of the resultset to be able to do "limit
>> > somthing offset length-your_negative_index" -- this doesn't seem to make 
>> > any
>> > sense for an ORM. You can always do list(qs)]:-1] though…
>>
>> It seems like the first comment in the ticket answers that question.
>> Django would reverse the sense of the query's ordering clause and use a
>> simple LIMIT.
>
>
> In my opinion it doesn't; eg imagine the following as query:
> MyModel.objects.order_by('whatever')[0:-50]; this isn't translateable into
> MyModel.objects.order_by('-whatever')[50:] (the issue here is that the end
> is now again undefined) since at least SQLite doesn't support an OFFSET
> clause without a LIMIT. Also I think it's more natural to rewrite the
> ordering of the query yourself to express that instead of using negative
> ranges.

At first glance, there's no important difference in offsets from one
end of an array or the other.

ORDER BY x ASC LIMIT 10 gives us the first 10 results in the ordered
list of result rows.
ORDER BY x DESC LIMIT 10 gives us the last 10 results in the ordered
list of result rows.

except that the overall ordering of output rows is different. So there
*is* a qualitative difference in negative indexing and I can see why
people think they want it. But there are a few problems since SQL
Standard does not provide a mechanism for this nor are any DBMS I'm
aware of tuned for that type of request. I understand why that is,
since "scroll all the way to end of result set" type logic isn't too
smart with arbitrary result set sizes that we see on databases,
whereas with Python array sizes are bounded much more significantly.

To implement this just in Django could be done in the following way.

If you want to see the data in one ordering (ASC), yet define the
LIMIT in another ordering you can either
1) retrieve via ASC: scroll all the way to the end of the result set,
then step back $LIMIT and read from there.
2) retrieve via DESC, apply LIMIT and then re-sort by ASC using two queries
3) retrieve via DESC, apply LIMIT and then re-sort by ASC using derived table
4) implement core logic for that into PostgreSQL

(1) would be very expensive with large result sets and should be avoided

(2) would optimise better but is hard to define generically.

(3) would require two sorts on the data like this

SELECT * FROM (rest-of-query ORDER BY ... DESC LIMIT n ) ORDER BY ... ASC

(4) though I'm not sure there'd be much interest in a not-very-useful
and non-standard SQL feature that would be non-trivial to implement


Django could support negative indexes, but it would require some
complex SQL that might not optimise well so it seems worth avoiding.

The order_by('-whatever') doesn't optimise well since this is a
function on the whatever column, which will defeat any attempt to
utilise an index to supply the ordering. i.e. it results in a
sequential scan and should be avoided.

I'd suggest an explicit option to change the ordering ASC | DESC,
which is matched by a SQL Standard feature.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Simon Litchfield]

Sorry I'm late back to the party boys and girls. 

Trivial as it may be, it's really just communication that's the only issue 
here, and I'm glad this has prompted a review. We all mean well and we're 
eager to help. The solutions Cal, Russ, Luke and co have discussed sound 
great. 

BTW- there are two Simon's here. I'm "simon29" from the original ticket, 
not "Simon" from this thread.


On Saturday, 11 May 2013 03:00:04 UTC+10, Simon wrote:
>
> Hi,
>
> When I started using Python a couple of months ago, a quick Google for 
> frameworks turned up a lot of results for Django so I decided to give it a 
> spin.
>
> I'd like to give some feedback on my experience to date. There are a lot 
> of features I really love, some that are a little quirky and some that are 
> downright inflexible. None of this will be news - it's the same for every 
> framework. That said, I started to have doubts when I was attempting to 
> find solutions/workarounds to the problems I encountered.
>
> Today was the 5th or 6th time that I've ended up at the ticket system and 
> seen people saying "This would really help me" and a core developer saying 
> "I don't see the need" (rather arbitrarily IMHO) and closing as wontfix. 
> This is invariably followed by people asking for reconsideration which in 
> turn gets a "use the mailing list" with varying degrees of rudeness.
>
> While I'm sure it's not the real reason, sending people to the mailing 
> lists feels like a way of brushing disagreement under the carpet. There's 
> no obvious way to follow on from the discussion in the ticket to the 
> relevant discussions in the mailing list (if any) and visitors coming by 
> years later now have to go and hunt through an archive to find out if 
> there's any chance of a change.
>
> I feel that the general attitude expressed in some of the tickets is poor. 
> The one which prompted this post is 
> https://code.djangoproject.com/ticket/901. I think comment 
> 20<https://code.djangoproject.com/ticket/901#comment:20> is 
> a good demonstration of my point. A couple of users were getting frustrated 
> at the lack of discussion/progress which resulted in a fairly sanctimonious 
> rant. 
>
> Some other tickets I've ended up on have proposed patches and seem to have 
> sat in "Design decision" for years, which again gives the impression that 
> the core team didn't like it so just sort of ignored it until it went away.
>
> So, to be honest, the impression I'm getting WRT new features in Django is 
> "Don't bother proposing it 'cos it's not going to happen".
>
> There are 
> StackOverflow<http://stackoverflow.com/questions/9791947/how-do-i-refresh-the-values-on-an-object-in-django>
>  
> questions<http://stackoverflow.com/questions/4377861/reload-django-object-from-database>
>  
> (another<http://stackoverflow.com/questions/15821581/django-how-to-refresh-or-reload-models-from-database>)
>  on 
> the topic and numerous other sources pointing at this particular ticket 
> wondering why it hasn't been implemented. The only reason I can see is that 
> "jacob" wasn't convinced by the (first) use case.
>
> Now, I admit that I'm probably seeing the worst side of the problem, there 
> are probably hundreds of other features which did get in (which is why 
> there's documentation not tickets for me to find) but that doesn't make the 
> situation I'm seeing better, just smaller.
>
> Perhaps the fact that people keep posting on closed tickets shows that the 
> current flow to the mailing lists isn't a good one? Maybe either add a 
> "Start a topic about this ticket" link or maybe even just allow discussion 
> to continue on the ticket as many others do?
>
> I'm unlikely to use Django moving forward. There are a number of reasons 
> and I'd be lying if I said this was the biggest but it was a factor in my 
> decision.
>
> Anyway, I wanted to take a few minutes and share the impressions I've had 
> to date - perhaps this way, others will have a better experience in future.
>
> Thanks for reading
>
> Simon
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Simon]

Apologies Daniele, I hadn't realised that had actually posted before I 
finished editing. I've now posted the final verison

On Friday, May 10, 2013 5:57:43 PM UTC+1, Daniele Procida wrote:
>
> On Fri, May 10, 2013, Simon <si...@exonar.com > wrote: 
>
> >Of course, once the ticket has been closed, the only way to appeal is 
> >through the mailing lists. To myself as a newcomer, that just feels like 
> a 
> >way of making further dissent less visible. I'm sure this isn't the case 
> >but that's certainly the feeling I got. 
>
> Surely the process should begin, not end, with the email list? Or better 
> still sometimes, #django-developers on irc.freenode.net. 
>
> Daniele 
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Perception of attitude in tickets

[Simon]

Hi,

When I started using Python a couple of months ago, a quick Google for 
frameworks turned up a lot of results for Django so I decided to give it a 
spin.

I'd like to give some feedback on my experience to date. There are a lot of 
features I really love, some that are a little quirky and some that are 
downright inflexible. None of this will be news - it's the same for every 
framework. That said, I started to have doubts when I was attempting to 
find solutions/workarounds to the problems I encountered.

Today was the 5th or 6th time that I've ended up at the ticket system and 
seen people saying "This would really help me" and a core developer saying 
"I don't see the need" (rather arbitrarily IMHO) and closing as wontfix. 
This is invariably followed by people asking for reconsideration which in 
turn gets a "use the mailing list" with varying degrees of rudeness.

While I'm sure it's not the real reason, sending people to the mailing 
lists feels like a way of brushing disagreement under the carpet. There's 
no obvious way to follow on from the discussion in the ticket to the 
relevant discussions in the mailing list (if any) and visitors coming by 
years later now have to go and hunt through an archive to find out if 
there's any chance of a change.

I feel that the general attitude expressed in some of the tickets is poor. 
The one which prompted this post is 
https://code.djangoproject.com/ticket/901. I think comment 
20<https://code.djangoproject.com/ticket/901#comment:20> is 
a good demonstration of my point. A couple of users were getting frustrated 
at the lack of discussion/progress which resulted in a fairly sanctimonious 
rant. 

Some other tickets I've ended up on have proposed patches and seem to have 
sat in "Design decision" for years, which again gives the impression that 
the core team didn't like it so just sort of ignored it until it went away.

So, to be honest, the impression I'm getting WRT new features in Django is 
"Don't bother proposing it 'cos it's not going to happen".

There are 
StackOverflow<http://stackoverflow.com/questions/9791947/how-do-i-refresh-the-values-on-an-object-in-django>
 
questions<http://stackoverflow.com/questions/4377861/reload-django-object-from-database>
 
(another<http://stackoverflow.com/questions/15821581/django-how-to-refresh-or-reload-models-from-database>)
 on 
the topic and numerous other sources pointing at this particular ticket 
wondering why it hasn't been implemented. The only reason I can see is that 
"jacob" wasn't convinced by the (first) use case.

Now, I admit that I'm probably seeing the worst side of the problem, there 
are probably hundreds of other features which did get in (which is why 
there's documentation not tickets for me to find) but that doesn't make the 
situation I'm seeing better, just smaller.

Perhaps the fact that people keep posting on closed tickets shows that the 
current flow to the mailing lists isn't a good one? Maybe either add a 
"Start a topic about this ticket" link or maybe even just allow discussion 
to continue on the ticket as many others do?

I'm unlikely to use Django moving forward. There are a number of reasons 
and I'd be lying if I said this was the biggest but it was a factor in my 
decision.

Anyway, I wanted to take a few minutes and share the impressions I've had 
to date - perhaps this way, others will have a better experience in future.

Thanks for reading

Simon

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Perception of attitude in tickets

[Simon]

Hi.

I'm a newcomer to both Python and Django and just wanted to share my 
experience trying to solve a couple of problems.

When I started coding in Python a month ago, Django was sufficiently common 
in Google searches that it was my first port of call. I've found quite a 
few features which I love and a few which seem a little quirky.

Unfortunately, every time I come across a problem, I seem to end up back at 
the ticket system which almost invariably results in lots of people saying 
"It's important to me" and a core developer saying (rather arbitrarily) "I 
don't see the need" and closing as wontfix.

Of course, once the ticket has been closed, the only way to appeal is 
through the mailing lists. To myself as a newcomer, that just feels like a 
way of making further dissent less visible. I'm sure this isn't the case 
but that's certainly the feeling I got.

The most recent example, which prompted this post is 
https://code.djangoproject.com/ticket/901 but this is the 5th or 6th time 
I've ended up at similar tickets with similar outcomes. I think comment 
#20 demonstrates 
my point perfectly - While the point being made is valid, the tone and 
general attitude is poor to say the least.

In any case, I shall be moving away from Django before I get too tied to 
it. I know this won't impact you in the slightest but I suspect other 
newcomers will be doing the same and not taking the time to post.

All the best

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Simon Riggs]

On 25 March 2013 12:37, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:

> I feel pretty strongly that NOT EXISTS semantics are wanted. The NOT
> IN semantics are likely there just because that is how the
> implementation was originally done, not because there was any decision
> to choose those semantics.

Most likely, yes, so it looks like a bug fix now not an optimization.

> Also, multicolumn NOT IN lookups aren't
> supported on all databases (SQLite at least), so for that case NOT
> EXISTS semantics is going to happen anyways.

Yes, I think that's the clincher.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Simon Riggs]

On 25 March 2013 10:58, Tim Chase <django.us...@tim.thechases.com> wrote:
> On 2013-03-25 03:40, Anssi Kääriäinen wrote:
>> I am very likely going to change the ORM to use EXISTS subqueries
>> instead of IN subqueries. I know this is a good idea on PostgreSQL
>> but I don't have enough experience of other databases to know if
>> this is a good idea or not.
>
> I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at
> $OLD_JOB, but there it's usually about the same, occasionally with IN
> winning out. However, the wins were marginal, and MSSQL is a 2nd-class
> citizen in the Django world, so I'm +1 on using EXISTS instead of IN,
> if the results are assured to be the same.

The results are definitely different because NOT IN has some quite
strange characteristics: if the subquery returns a NULL then the whole
result is "unknown". It is that weirdness that makes it hard to
optimize for, or at least, not-yet-optimized for in PostgreSQL.

In most cases it is the NOT EXISTS behaviour that people find natural
and normal anyway and that is the best mechanism to use.

> However, the query constuction to move the condition into the EXISTS
> subclause might be a bit more complex.


-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: postgresql range types v2

[Simon Litchfield]

Also, did you see psycopg2.extras.DateTimeRange?

On Monday, December 31, 2012 8:56:12 PM UTC+11, mpaolini wrote:
>
> Hi all, 
>
> sorry for the noise, forget my previous mail as it was pointing to the 
> wrong commit, 
> here's the good one: 
>
>
> https://github.com/mpaolini/django/commit/b754abdeab204949510500ccb1b845b7ad143542
>  
>
> copying here the rest of the original mail: 
>
> postgresql since version 9.2 added support for range types [1] 
> they have a nice set of specialized operators like "overlaps", "left of", 
> etc... [2] 
>
> So I decided to work on a reference implementation for Django 
> even if it looks like psycopg2 does not fully support yet these data types 
> [3] 
>
> The implementation is only a proof of concept and is not complete and not 
> tested 
> (but it does contain tests, of course!) 
>
> I did: 
>   - datetime range python data type: two bounds plus inclusive/excusive 
> info (very basic!) 
>   - datetime range model field 
>   - range specific lookups for querysets 
>   - non-overlapping constraint: db-level enforced with sql CONSTRAINT and 
> model validation 
>   - some documentation 
>
> TODO: 
>   - form, widget, modelform, localization, admin 
>   - more range types (int, bigint, etc...) 
>   - more validation against invalid ranges 
>   - better range type python implementation 
>   - more testing 
>
> Do you like it? Any chances for it to land in master once it is completed? 
> Or is it too specialized? 
>
> Cheers, 
>
> Marco 
>
> [1] http://www.postgresql.org/docs/9.2/static/rangetypes.html 
> [2] 
> http://www.postgresql.org/docs/9.2/static/functions-range.html#RANGE-OPERATORS-TABLE
>  
> [3] http://archives.postgresql.org/psycopg/2012-09/msg00051.php 
>
>

-- 
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/-/shC1MhFZg4YJ.
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: postgresql range types v2

[Simon Litchfield]

Marco, this is great. 

I wonder if it would be possible to add range fields without modifying 
django? 


On Monday, December 31, 2012 8:56:12 PM UTC+11, mpaolini wrote:
>
> Hi all, 
>
> sorry for the noise, forget my previous mail as it was pointing to the 
> wrong commit, 
> here's the good one: 
>
>
> https://github.com/mpaolini/django/commit/b754abdeab204949510500ccb1b845b7ad143542
>  
>
> copying here the rest of the original mail: 
>
> postgresql since version 9.2 added support for range types [1] 
> they have a nice set of specialized operators like "overlaps", "left of", 
> etc... [2] 
>
> So I decided to work on a reference implementation for Django 
> even if it looks like psycopg2 does not fully support yet these data types 
> [3] 
>
> The implementation is only a proof of concept and is not complete and not 
> tested 
> (but it does contain tests, of course!) 
>
> I did: 
>   - datetime range python data type: two bounds plus inclusive/excusive 
> info (very basic!) 
>   - datetime range model field 
>   - range specific lookups for querysets 
>   - non-overlapping constraint: db-level enforced with sql CONSTRAINT and 
> model validation 
>   - some documentation 
>
> TODO: 
>   - form, widget, modelform, localization, admin 
>   - more range types (int, bigint, etc...) 
>   - more validation against invalid ranges 
>   - better range type python implementation 
>   - more testing 
>
> Do you like it? Any chances for it to land in master once it is completed? 
> Or is it too specialized? 
>
> Cheers, 
>
> Marco 
>
> [1] http://www.postgresql.org/docs/9.2/static/rangetypes.html 
> [2] 
> http://www.postgresql.org/docs/9.2/static/functions-range.html#RANGE-OPERATORS-TABLE
>  
> [3] http://archives.postgresql.org/psycopg/2012-09/msg00051.php 
>
>

-- 
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/-/EXxINLYk-hgJ.
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: RedirectView supporting View-Names

[Simon Meers]

See https://code.djangoproject.com/ticket/15273


On 23 November 2012 23:30, Ludwig Kraatz  wrote:

> Hi,
>
> is there a specific reason why the RedirectView does not have a
> "view_name" attribute and out-of-the-box supporting to reverse it?
>
>   if self.url:
>  url = self.url
>   elif self.view_name:
>  url = reverse(self.view_name, kwargs=kwargs, request=request)
>   else:
>  return None
>
> best regards
> ludwig
>
> --
> 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/-/YaZrSyhb7fEJ.
> 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: Python 3: should we apply unicode_literals everywhere?

[Simon Meers]

It's a shame we couldn't skip straight to Python 3.3 and take
advantage of PEP414...

On 22 August 2012 07:32, Adrian Holovaty  wrote:
> On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin
>  wrote:
>> In my opinion, option (2) is a logical move at this point. However I
>> believe it deserves a public discussion (or at least an explanation).
>> What do you think?
>
> I prefer option 2 as well, because it seems like the Right Thing To
> Do. Of course, there's no rush to do everything -- we can just nibble
> off bits here and there.
>
> I'll have some free time soon and would be happy to help out migrating
> code. (Relatively) mindless refactoring like this is one of my
> favorite things to do. :-)
>
> Adrian
>
> --
> 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: Python 3 - style question

[Simon Meers]

> On 10 August 2012 18:56, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>> I think Option 2 is better, for the reasons you state.

+1. And it's not too entangled to be easily stripped out if/when
Python 2 support is removed.

On 11 August 2012 06:10, Łukasz Rekucki <lreku...@gmail.com> wrote:
> How about wrapping those 3 lines of code into a class decorator
> (preferably named more explicit then StrAndUnicode) ? That would be at
> least a little DRY.

+1. It won't mess with the inheritance hierarchy, and is explicit
enough (depending on the name), whilst encapsulating the boilerplate
elegantly. @python2_unicode_compatible?

(Though, @-syntax class decorators are only available from 2.6+, but
I'm guessing we won't be able to drop 2.5 support at the same time as
picking up 3. I guess we could just tidy up when we do.)

Simon

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

Django Sprint at PyCon Australia 2012 -- Monday 20th August

[Simon Meers]

Monday 20th August 0900-2359 AEST at PyCon Australia 2012 (Hobart) [1]

The Interaction Consortium [2] have kindly offered to provide pizza
and beer (presumably only for those physically present ;)

Join us via the #django-sprint IRC channel on Freenode; see [3] for
more information.

[1] http://2012.pycon-au.org/programme/sprints
[2] http://interaction.net.au
[3] https://code.djangoproject.com/wiki/Sprints

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

ModelForm.Meta.overrides

[Simon Meers]

A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm
violently -1 on the whole topic "meta programming form fields after they've
been instantiated", it's a mess. Yes it would be more DRY, but also much
harder to know how the hell the form fields are composed as. Just override
the form field, it's not a huge deal code wise and much easier to grok." This
has since been contested [2] (though for invalid reasons in my opinion).

I'm not sure that Jannis and I were talking about the same thing; the
solution I had in mind did not involve changing form-fields after their
instantiation, but rather providing a more elegant and flexible mechanism
that works in a similar way to ModelForm.Meta.widgets and
formfield_callback.

I've put a draft patch together and attached it to [1] which should give a
better indication of the intended approach and its flexibility and
benefits. There are still a few details to iron out in evolving the ideal
implementation, but this at least demonstrates the gist of it. Does anyone
else think this is worth exploring?

Simon

[1] https://code.djangoproject.com/ticket/17924
[2] *
https://groups.google.com/d/msg/django-developers/x_nJ5epfG18/ZSKcPW0_DvAJ*

-- 
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: Allow changing form field properties after form creation

[Simon Meers]

On 6 April 2012 07:26, Beres Botond <boton...@gmail.com> wrote:
> Hi Chris,
>
> Isn't it this what you are trying to do?
>
> class DocumentForm(ModelForm):
>        def __init__(self, *args, **kwargs):
>                super(MyForm, self).__init__(*args, **kwargs)
>                self.fields['title'].required = False
>
> Which works perfectly fine. You can tweak pretty much any property at
> runtime like that, without replacing the field entirely.

This discussion is sounding more like something that belongs in
django-users. I agree that there are some improvements that can be
made to make field-tweaking easier and more elegant, as proposed in
[1] which Keryn pointed out in [2]. It would probably be better to
continue this conversation in those tickets.

Simon

[1] https://code.djangoproject.com/ticket/17924
[2] https://code.djangoproject.com/ticket/18064

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

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

[Simon Charette]

Now deprecated generic create_update function based views 
(create_object<https://github.com/django/django/blob/master/django/views/generic/create_update.py#L100-126>,
 
update_object<https://github.com/django/django/blob/master/django/views/generic/create_update.py#L138-169>,
 
delete_object<https://github.com/django/django/blob/master/django/views/generic/create_update.py#L183-221>)
 
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<https://docs.djangoproject.com/en/dev/ref/contrib/messages/#s-failing-silently-when-the-message-framework-is-disabled>
.

Here's wip 
patch<https://github.com/charettes/django/compare/class-based-generic-edit-views-messages.diff>to
 backport this feature for class based views that I can attach to a 
ticket if this get acknowledged as a missing feature. I can also submit a 
doc revision in the other case.

Simon
<https://github.com/charettes/django/compare/class-based-generic-edit-views-messages.diff>

-- 
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/-/E-yNGQ2D1zIJ.
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: End-user defined fields, how would you approach it?

[Simon Charette]

I've been working on a similar project which takes the django-dynamo 
project a bit further.

It's undocumented ATM but you can find the code at: 
https://github.com/charettes/django-mutant

-- 
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/-/x6uWMd1KF3QJ.
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: ModelBackend should have a get_anonymous_user method

[Simon Meers]

Hi Ric,

On 18 November 2011 19:53, Ric <riccardodivirgi...@gmail.com> wrote:
> ...
> i've created a ticket
> https://code.djangoproject.com/ticket/17254

Thank you for your contributions of late. Please note that you don't
need to email django-developers when you create a new ticket; we
receive notifications through django-updates and monitor Trac.

Simon

-- 
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: First time contribution, tests fails.

[Simon Charette]

Hi Yasar!

Are you sure you're at the latest trunk revision? (16911)

I'm not getting any failures with this revision and the test_sqlite 
settings?

http://dpaste.com/623028/

-- 
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/-/BFgwixc7umUJ.
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: API for introspecting models

[Simon Charette]

It might be worth it to look at this existing effort to document _meta: 
http://readthedocs.org/projects/django-model-_meta-reference/.

Simon

-- 
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/-/FxTT4AIHOG8J.
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 doesn't work with Oracle 11g on Windows 8

[Simon Charette]

http://lmgtfy.com/?q=vcvarsall.bat

-- 
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/-/v6EuZV0jI6AJ.
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: Improvements to better support implementing optimistic concurrency control

[Simon Riggs]

On Wed, Aug 10, 2011 at 3:08 PM, Anssi Kääriäinen
<anssi.kaariai...@thl.fi> wrote:
> On 08/10/2011 03:18 PM, Simon Riggs wrote:
>
> That adds additional SELECT statements, which then extends a lock
> window between the check statement and the changes. It works, but in
> doing so it changes an optimistic lock into a pessimistic lock.
>
> True. The issue I am trying to solve is: Guard against concurrent
> modifications to some
> object without taking a lock when the edit page is loaded. I did some
> Googling and I see this is not what is meant by optimistic locking. Sorry
> for that.

The problem we're all trying to solve is that we don't want locks to
be held across multiple SQL statements.

If we do this

IDEA 1
(0) BEGIN
(1) SELECT... FOR UPDATE
(2) UPDATE
(3) COMMIT

then the lock is taken at (1) and held all the way until commit at (3).

Avoiding that is desirable, and is known as optimistic locking.

IDEA 2
(1) SELECT data & version
(2) UPDATE data & test version & COMMIT immediately

Here we don't take the write lock until (2) and so the lock window is
much shorter.

If we do this using an additional SQL statement like this

IDEA 3
(1) SELECT data & version
(2) SELECT data & test version
(3) UPDATE data & COMMIT immediately

then we add in an extra SQL statement, though now we have a race
condition between steps (2) and (3)  so this should be avoided

in favour of

IDEA 4
(1) SELECT data & version
(2) SELECT data & test version & FOR UPDATE
(3) UPDATE data
(4) COMMIT

which avoids the race condition inherent in IDEA 3. But IDEA 4 now has
exactly the same problem as IDEA 1 had in the first place, so we
haven't solved the problem.

So IDEA 2 is the only one that avoids holding long locks and avoids
race conditions.


> IMHO the right way to do this would be to add the OptimisticLockField
> check as an additional item on the WHERE clause of the UPDATE or
> DELETE. If that action returns 0 rows then we know that the lock check
> failed and we can handle that. This keeps the locking optimistic and
> doesn't add any additional SQL statements.
>
> e.g.
>
> UPDATE foo
> SET col = newvalue, optimistic_lock_field = optimistic_lock_field + 1
> WHERE pkcol = p_key
> AND optimistic_lock_field = p_version
>
> DELETE FROM foo
> WHERE pkcol = p_key
> AND optimistic_lock_field = p_version
>
> The problem with this is that I feel the checking should be done already in
> data validation part, not when saving is already under way. But I guess that
> is use case specific. Doing the checking while saving will result into
> situations where half of the stuff is saved and the other half is not. The
> model.save() isn't atomic itself without a savepoint due to model
> inheritance. And if it is not atomic, then it is easy to do a half-update
> using the shell, for example.

As I show above, the proposed patch doesn't solve the problem, I am
sorry to say.

Yes, not updating atomically is a problem. Doing the updates
atomically could also create a deadlock risk. It's a hard problem.

> On the other hand, if a clean implementation is written for this, including
> it in Django would be really nice. This doesn't cost much in performance,
> and gives a nice guard against concurrent edits. BTW there is more
> discussion in the ticket #16549
> (https://code.djangoproject.com/ticket/16549).

The very best way to do this from the database perspective is to use
the SQL Standard RETURNING clause, which allows you to return the data
after the update

IDEA5
UPDATE foo
SET val = x
WHERE pk = y
RETURNING data

but I can see that causing a few discussion points, so I didn't
mention it previously.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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: Improvements to better support implementing optimistic concurrency control

[Simon Riggs]

On Tue, Aug 9, 2011 at 1:33 PM, akaariai <akaar...@cc.hut.fi> wrote:
> On Aug 9, 1:17 am, Steven Cummings <estebis...@gmail.com> wrote:
>> I don't think we're talking about new or specific fields as part of the base
>> implementation here. Just enhanced behavior around updates to:
>>
>> 1) Provide more information about the actual rows modified
>> 2) Check preconditions with the actual DB stored values; and
>> 3) Avoid firing post-update/delete signals if nothing was changed
>>
>> From there you could implement fields as you see fit for your app, e.g.,
>> version=IntegerField() that you use in a precondition.
>
> That would be useful. Especially if that can be done without too much
> code duplication.
>
> I had another idea for optimistic locking: why not use the pre_save
> signal for this? There is a proof of concept how to do this in
> https://github.com/akaariai/django_optimistic_lock
>
> The idea is basically that if you add a OptimisticLockField to your
> model, the pre_save (and pre_delete) signal will check that there have
> been no concurrent modifications. That's it.
>
> The code is really quickly written and downright ugly. It is a proof
> of concept and nothing more. I have tested it quickly using PostgreSQL
> and it seems to work for simple usage. However, it will probably eat
> your data.

That adds additional SELECT statements, which then extends a lock
window between the check statement and the changes. It works, but in
doing so it changes an optimistic lock into a pessimistic lock.

IMHO the right way to do this would be to add the OptimisticLockField
check as an additional item on the WHERE clause of the UPDATE or
DELETE. If that action returns 0 rows then we know that the lock check
failed and we can handle that. This keeps the locking optimistic and
doesn't add any additional SQL statements.

e.g.

UPDATE foo
SET col = newvalue, optimistic_lock_field = optimistic_lock_field + 1
WHERE pkcol = p_key
AND optimistic_lock_field = p_version

DELETE FROM foo
WHERE pkcol = p_key
AND optimistic_lock_field = p_version

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Simon Charette]

How is that supposed to interact with the `cleaning` mechanism of the field?

-- 
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/-/BNMXjILUK7gJ.
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: Deferred constraint checking causing problems during test runs

[Simon Riggs]

On Thu, Jul 14, 2011 at 2:36 PM, Jim Dalton <jim.dal...@gmail.com> wrote:

> So in normal, everyday use, Django opens a connection to Postgresql with an
> open transaction. Per the docs, it commits this transaction immediately
> whenever you do an INSERT or UPDATE etc. At that point Postgresql would run
> its constraint checks and rollback the transaction on error or else commit.

Yes, each statement is a transaction in itself unless you explicitly
request an extended transaction.

> During a test, we open up a big transaction during setUp and then *disable*
> the transaction commit and rollback operations, i.e. a call to either does
> nothing. Since we can't nest transactions in Postgresql (right?) this has
> been the only sensible way to allow tests to proceed. The problem has been
> -- I am positing -- that we're getting away with a lot of stuff as a result,
> because constraint checks are *never* checked during testing. The small slew
> of bugs I found is a demonstration of that, to me.

No, sorry, nested transaction commands aren't supported.

> Anyhow, thank you once again Simon for shedding light on this for me.

No problem. Thanks to everybody working on Django.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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: Deferred constraint checking causing problems during test runs

[Simon Riggs]

On Sun, Jul 10, 2011 at 3:27 PM, Jim Dalton <jim.dal...@gmail.com> wrote:
> On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote:
>
>> Maintaining the property of deferrable constraints seems important
>> here, so changing the deferrability of constraints, or overriding it
>> using the SET CONSTRAINTS command at the top of the transaction might
>> not be what we want.
>
> Well, that's just it. We want tests to behave as much like production code as 
> possible, so we actually *don't* want constraint checks to be deferred.
>
> When you're working with DB normally in production, i.e. outside of a 
> transaction, constraints are checked immediately. It's only when you get into 
> a transaction that they are deferred. Each of our tests run inside of a 
> transaction, which is an artificial construct. So to emulate production, I'm 
> arguing that this property is not something we want (*unless* we are testing 
> a transaction or transaction like behavior, in which case it does make sense 
> to temporarily suspend constraint checks).

My role here is to help with Postgres details, so any comments I make
are just attempts at providing useful information.

It sounds like there is a slight confusion about the way PostgreSQL
works. Everything is a transaction, so there is no difference between
inside/outside a transaction.

You can choose whether you wish immediate or deferred constraint
checking. It's completely user selectable, though the default is
immediate. If you're seeing deferred checks, they can be changed.

ISTM that the tests should work the same way as things do in
production, and it looks possible to make that happen.

>> What I would recommend is that we issue an explicit SET CONSTRAINTS
>> ALL IMMEDIATE command immediately before the ROLLBACK at *end* of
>> test. This will fire any outstanding checks. That way all constraint
>> checks will occur in the same place they would during a commit, yet we
>> can maintain the situation that the test ends with a rollback.
>
> This would conceivably work I think. I'm pretty sure Ramiro was exploring 
> this approach actually. My feeling, however, is that this still allows you to 
> get away with stuff you might not otherwise get away with in production. I 
> also think it's more helpful seeing exactly where an integrity issue came up 
> so you can address it. This is, for example, what allowed me to understand 
> the handful of bugs that were hiding, i.e. because I could trace the 
> Intergrity Error to the exact line of code that was triggering it.

It does seem sensible to make the tests work like production. Are we
sure they are different, given comments above?

> Your questions raise one issue that had not occurred to me though. One 
> possible "problem" with putting constraint checks at the beginning is that 
> there is now way for a test to recover from them. If you try to put bad data 
> into the DB with immediate constraint checks on, you will raise and error 
> *and* if I'm not mistaken the transaction will be rolled back at that very 
> instant. So if for some reason you knew you were putting bad data in and 
> wanted to recover from it in your test and keep going, that would not be 
> possible. I'm not sure that's actually a problem, but it's certainly 
> something to consider. It's another dimension of behavior that is changed.

If you want to recover from an error and then continue, you can use
SAVEPOINTs. These allow you to put a mark in the sand and return to it
in case of error.

e.g. in SQL

BEGIN;

INSERT  -- succeeds

SAVEPOINT s1

INSERT -- fails check

ROLLBACK to SAVEPOINT s1;

INSERT  -- succeeds

COMMIT;

I hope that info helps the decision process.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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: Deferred constraint checking causing problems during test runs

[Simon Riggs]

On Sun, Jul 10, 2011 at 5:35 AM, Jim D. <jim.dal...@gmail.com> wrote:

> The problem is that by default in most of our backends, a transaction runs
> with constraint checks deferred. This means that foreign keys are *not*
> checked for integrity until a transaction is committed. But here's the rub:
> we never commit a transaction during tests, we roll it back instead.
> Therefore, none of the queries against the DB are being checked for
> integrity. (The exception is MySQL InnoDB, which I'll get to in a sec.)
> As part of the work I was doing recently to disable and re-enable constraint
> checks during fixture loading, I realized that we were handling this sort of
> incorrectly across our backends.  Postgresql in fact does provide a facility
> for enabling constraint checks: SET CONSTRAINT CHECKS ALL IMMEDIATE. This
> statement causes Postgresql to behave as it normally would, when it was
> executing queries outside of a transaction.

By default, PostgreSQL creates all constraints as NOT DEFERRABLE. To
get the observed behaviour we'd need to be explicitly defining
constraints as DEFERRABLE INITIALLY DEFERRED.

Maintaining the property of deferrable constraints seems important
here, so changing the deferrability of constraints, or overriding it
using the SET CONSTRAINTS command at the top of the transaction might
not be what we want.

What I would recommend is that we issue an explicit SET CONSTRAINTS
ALL IMMEDIATE command immediately before the ROLLBACK at *end* of
test. This will fire any outstanding checks. That way all constraint
checks will occur in the same place they would during a commit, yet we
can maintain the situation that the test ends with a rollback.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

[Simon Riggs]

On Wed, Jun 29, 2011 at 9:27 PM, akaariai <akaar...@cc.hut.fi> wrote:
> On Jun 28, 5:46 pm, Javier Guerra Giraldez <jav...@guerrag.com> wrote:
>> 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.
>>
>
> I really do hope that the CASE WHEN construction can be used in all
> supported databases. I have high hopes that it can be used, because
> the CASE WHEN construction is one of the most standard constructions
> in SQL, and because I have tested it on MySQL 5.0, PostgreSQL 8.4,
> SQLite3 and Oracle 10g.

The CASE syntax is definitely SQL Standard, so that part is OK. I'm
sure we'll discuss some weird NULL handling or similar somewhere.

I'm not sure I like your ORM syntax to generate that though. Why not
just pass through the case statement directly? That way *any* legal
CASE statement can be used, without inventing new ORM syntax each
time.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
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: Default project layout / directory structure

[Simon Litchfield]

On Mar 15, 9:46 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Fri, Mar 11, 2011 at 1:14 PM, Simon Litchfield <si...@s29.com.au> wrote:
> > Who votes we should come up with a django-blessed 'official' default 
> > project layout / directory structure?
>
> Sure -- no disagreement that it would be good to have some common
> ground with regards to project layout. All we need now is to agree
> what that blessed project layout should be. :-)

Lowest common denominator is what we're after here I think. Eg --

manage.py
--conf
settings.py
settings_dev.py
--lib
other_app1
other_app2
--my_app1
--my_app2
--media
--templates
--templatetags (project tags, non-app specific, if you have any)
--views.py (project views, non-app specific, if you have any)
--urls.py (project urls, non-app specific)

Or maybe this --

manage.py
--conf
settings.py
settings_dev.py
(wsgi files)
--lib
other_app1
other_app2
--project
my_app1
my_app2
templatetags (project tags, non-app specific, if you have any)
views.py (project views, non-app specific, if you have any)
urls.py (project urls, non-app specific)
--media
css
img
js
uploads
--templates

This way we keep our pythons separate from our chickens.

Also to suggest a preferred media structure or not- at least a
centralised uploads / var media folder would be good practice I think,
at least from provisioning and permissions etc point of view.

Thoughts? These are just a few suggestions to get the conversation
started!

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

Default project layout / directory structure

[Simon Litchfield]

Who votes we should come up with a django-blessed 'official' default project 
layout / directory structure?

Might sound like a triviality, but sometimes it's the little things.

1. Newcomers -- startproject throws 9/10 into confusion and results in a messy 
first few projects.

2. Gurus -- each have their own way, what a waste, not DRY.

3. The new breed of django hosting platforms that are on their way -- gives 
them something to base their tools on.

Why not have a standard way, standard tools, etc etc- built in, batteries 
included. DRY.

Whether it be a plain old manage.py-friendly directory layout, something 
virtualenv+pip powered, maybe something like Lincoln Loop's startproject style, 
Eric Holscher's, or whatever. Lets not go too nuts on directories though, they 
get tiring (especially in textmate)

Thoughts?

-- 
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: type-field model inheritance

[Simon Meers]

Hi Carl,

> FWIW, django-model-utils [1] includes an InheritanceManager that
> implements polymorphic queries in a single query via select_related.

Ah, there goes my theory that I thought of it first :) And of course
introspection of subclasses via the reverse OneToOne descriptors is
perfect.

-- 
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: type-field model inheritance

[Simon Meers]

On 4 March 2011 17:03, Craig de Stigter <craig...@gmail.com> wrote:
> Hi guys
>
> Thanks for pointing those out. I knew I couldn't have been the first to want
> this. I guess I just didn't know the right words to search for here.
> It looks like django_polymorphic does what I want. I'm not yet sure why it
> says it takes one query per type of model in a queryset. Unless it is
> talking about multi-table inheritance, in which each type would require a
> different join. But I'll look in more detail in the next few days and no
> doubt it will become clear.

+1 for better polymorphic support in Django core; it is a very common
problem which could do with an efficient and elegant solution.
Regarding efficiency, if you can keep track of your subclasses
effectively (potentially using a registry if not introspection), you
can use select_related to retrieve heterogeneous multi-table
inheritance models in a single query (see example in [1]). I haven't
looked deeply enough into django_polymorphic to see if it includes
such optimisations. I'm sure we could further tweak the internals to
make things more efficient and developer-friendly in this regard.

Cheers,
Simon

[1] http://stackoverflow.com/q/5175009/284164

-- 
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: pb with search on website

[Simon Charette]

This addon[1] has not been updated since the doc were and doesn't work 
anymore.

You can try this updated version[2] I use which works fine.

[1] https://addons.mozilla.org/en-US/firefox/addon/django-docs-search/
[2] https://gist.github.com/813029

-- 
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.forms.fields.Field.localize to default to settings.USE_L10N

[Simon Charette]

Thank you very much for your feedback, I was wondering
what were the edge cases that motivated such a decision.

Do you believe it makes sense to have such a switch at
the Form level, say a localize keyword which it's fields
would default to? The same could apply to ModelAdmin
localize_forms. If so i'll file a feature request whith a patch
and tests. I might need some help on doc however.

Simon

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

django.forms.fields.Field.localize to default to settings.USE_L10N

[Simon Charette]

Hi, I encountered a problem with DecimalField and DECIMAL_SEPARATOR in the 
admin which lead me
to a ticket [1] which was marked as worksforme.

Well it wasn't quite workingforme so I tried to come up with a testcase 
since the ticket has none.

I realised that the actual implementation of DecimalField was working 
perfecly when it was initialized
with the "localize=True" kwarg. Which lead me to a larger issue concerning 
admin not considering
settings.USE_L10N: ModelAdmin.formfield_for_dbfield should pass the 
localize=True kwarg if
settings.USE_L10N=True. IMHO it's an expected behavior.

I'm also wondering if the issue shouldn't be tackled at the 
forms.fields.Field API level instead.
What about defaulting Field.__init__ localize kwarg to settings.USE_L10N?

Simon

[1] http://code.djangoproject.com/ticket/14101

-- 
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: Feature request: Abstract ManyToManyField

[Simon Meers]

2011/2/5 Carl Meyer <carl.j.me...@gmail.com>
>
> Hi Mike,
>
> On Feb 3, 4:36 pm, Mike Lindsey <mike-dja...@5dninja.net> wrote:
> > I'm doing something with bidirectional ManyToManyFields, in a project
> > I'm working on, that is resulting in duplicate attempts to create the
> > intermediate tables.  I'm perfectly open to suggestions of "You're
> > doing it wrong" if they come with advice on how to fix my problem,
> > without losing the easy Admin insertion of the relationships (without
> > resorting to InLines, which don't seem to play nicely at all with
> > FieldSets).  Right now I'm getting around the problem by running
> > syncdb, running dbshell to drop the table it complains about, and
> > rerunning syncdb; repeating until syncdb finishes successfully.
> >
> > What would make this exceptionally easy, is if there was the option to
> > set 'abstract=True' on second iteration of each of the
> > ManyToManyFields, telling syncdb to not attempt to create it.
>
> So what you're trying to do here is simply not supported. I'm guessing
> you've already concluded as much. This means that, for now, there is
> no good answer for you (that I'm aware of). Whatever hack or
> workaround you are able to come up with is what you're gonna get.
> Sorry.

BTW the ticket for this is #897 [1] and there is a suggested
workaround (explicit declaration of the 'through' table) which isn't
*too* ugly and might help you in the short-term?

Simon

[1] http://code.djangoproject.com/ticket/897

-- 
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: Need advice on ticket #14928 (manage runserver does not allow host name as address)

[Simon Meers]

> I don't know how many people actually used that feature (I never did),
> but it seems like it was a bit accidental. As we are speaking about a
> development server, I don't find this feature very useful as (most of
> the time) you want to run it on a host-only address, which won't have
> many aliases other than "localhost". You could add more in your
> "hosts" file or have a DNS on intranet map to your machine, but it
> sounds like a really rare case.
>

I actually use this all the time; my /etc/hosts has an entry for almost
every Django project I work on; this way the browser maintains separate
cookies for each one, so I don't have to keep logging in/out, etc. I'd be
very disappointed to see this functionality disappear.

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Custom FilterSpecs

[Simon Litchfield]

Honza's #5833 is nifty. It's a pity it missed the cut last year for
1.1. It's been kicking around for 3 years, and there seems to be
plenty of similar tickets that it'd address too.

Any chance for 1.3? Is it just the lack of tests/docs or are there
design concerns?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: prepopulated_fields javascript error since r14123

[Simon Meers]

On 30 October 2010 07:50, Andrew Godwin  wrote:

>
>  It's working fine for me on my freshly-updated 1.2.X branch - did you make
> sure the caches were clear, etc, etc?
>


Yes, and I'd experienced it on several different
servers/projects/client-machines. Yet I've just tested it on a new project
also, and it seems to be fine, as you say. I've discovered that in one of
the projects someone had set up a
"templates/admin/prepopulated_fields_js.html" template (why?!) which
contained the old javascript join code! No idea what the cause was on the
other projects, but I'm guessing the core code is fine; sorry for the
confusion.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: prepopulated_fields javascript error since r14123

[Simon Meers]

On 27 October 2010 19:40, Andrew Godwin <and...@aeracode.org> wrote:

> On 27/10/10 07:01, Simon Meers wrote:
>
>> Has anyone else found that using prepopulated_fields in admin.ModelAdmin
>> since r14123 produces a javascript error: "d.join is not a function"?
>>
>
> I didn't get any errors when I tested the patch before commit - are you
> having them on the 1.2.X backport, or the main trunk version?
>

On the 1.2.X backport; that sounds likely to be the reason it hasn't been
picked up.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

prepopulated_fields javascript error since r14123

[Simon Meers]

Has anyone else found that using prepopulated_fields in admin.ModelAdmin
since r14123 produces a javascript error: "d.join is not a function"?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Permission support for admin inlines

[Simon Meers]

On 27 October 2010 08:15, Simon Litchfield <si...@slicmedia.com> wrote:

> The ModelAdmin's permission hooks are great- has_add_permission,
> has_change_permission, and has_delete_permission.
>
> It would be nice if they were supported by inlines in the same way; ie
> InlineModelAdmin, StackedInline, TabularInline, GenericStackedInline,
> GenericTabularInline.
>
> UI is fairly obvious; has_add would result in no add form; has_delete
> in no delete tick box; and for has_change, showing as readonly_fields
> would probably be easiest.
>
> Any thoughts?
>
>
This should be considered together with the question of whether the user's
general permissions should apply to inlines [1], which is in DDN at present.

[1] http://code.djangoproject.com/ticket/8060

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Permission support for admin inlines

[Simon Litchfield]

The ModelAdmin's permission hooks are great- has_add_permission,
has_change_permission, and has_delete_permission.

It would be nice if they were supported by inlines in the same way; ie
InlineModelAdmin, StackedInline, TabularInline, GenericStackedInline,
GenericTabularInline.

UI is fairly obvious; has_add would result in no add form; has_delete
in no delete tick box; and for has_change, showing as readonly_fields
would probably be easiest.

Any thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #3400 -- ModelAdmin.list_filter improvements

[Simon Meers]

Anyone? I know it is a relatively complex patch to review, but it would be a
shame to see such a frequently requested feature/fix miss the 1.3 boat.

On 29 August 2010 08:06, Simon Meers <drme...@gmail.com> wrote:

> A gentle reminder to anyone who would like to review the recent patch
> uploaded for #3400 [1].
>
> I have come across quite a number of people who consider list_filter's
> current inability to span relationships (e.g. as search_fields can) to be
> one of the more obvious/annoying of Django's limitations and would love to
> see it implemented.
>
> [1] http://code.djangoproject.com/ticket/3400
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Something.is_live instead of implementation specific is_live settings

[Simon Meers]

If everything is under version control, you'll need to detect the server
status somehow. Some options:
- check the absolute path of the settings file on the filesystem if you can
ensure this path is different on the production server
- import socket; and check socket.gethostname()
- check for "runserver" in sys.argv
- etc.

On 25 September 2010 06:50, Yo-Yo Ma  wrote:

>
> What if I want dev settings in version control?
>
> What if I want "explicit"?
>
>
> On Sep 24, 11:09 am, "burc...@gmail.com"  wrote:
> > How it's better from both of the following:
> >
> > 1)
> > try:
> > from dev_settings import *
> > except ImportError:
> >pass
> >
> > 2)
> > if DEBUG:
> > from dev_settings import *
> >
> > Because to have "project.is_dev" you'll have to write it somewhere
> already!
> >
> > It's bootstrapping problem.
> >
> >
> >
> >
> >
> > On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma 
> wrote:
> > > I read that article. The problem is that it's deployment specific. I
> > > dint even know what host name "omh.cc" is, but I have a feeling that
> > > you couldn't work on that from your laptop to your desktop without
> > > changing something. What I propose isn't a is_production variable. I'm
> > > proposing an explicit is_development variable so that I can choose my
> > > settings "explicitly" instead of trying to import something and then
> > > something else if that's not there. That is very un-pythonic. If I can
> > > say something to the effect of:
> >
> > > if project.is_dev:
> > >import dev_settings
> > > else:
> > ># is live
> >
> > > just example. I'm not suggesting "project" as a global. It's just to
> > > show the type of setting I want.
> >
> > > That's much cleaner, and far more explicit than "import os, socket,
> > > etc".
> >
> > > On Sep 23, 7:41 pm, Yo-Yo Ma  wrote:
> > >> Thanks for the link David. I'm gonna check it it now.
> >
> > >> On Sep 23, 6:16 pm, "David P. Novakovic" 
> > >> wrote:
> >
> > >> > This link and the comments suggest some good stuff... particularly
> the
> > >> > comment from Malcolm and the original post.
> >
> > >> >
> http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
> >
> > >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
> >
> > >> >  wrote:
> > >> > > The thing is, in production mode you normally have to define where
> > >> > > your settings are anyway, so you pass the unusual settings file
> name
> > >> > > there, and just use the regular settings.py for your development.
> >
> > >> > > So then you are passing the settings configuration information
> once in
> > >> > > the production server's configuration, not every time you run your
> > >> > > development server.
> >
> > >> > > I think people with any decent sized project have addressed this
> issue
> > >> > > in their own way that suits their own needs.
> >
> > >> > > For example we have lots of settings files and just import the
> > >> > > relevant settings into a final file.
> >
> > >> > > For testing I do what i mentioned in my previous email.
> >
> > >> > > Like anything on here, you need to ask whether what you are
> suggesting
> > >> > > would actually be better off as part of the core or if it works
> just
> > >> > > fine as something that people can choose to use themselves...
> >
> > >> > > I think most people use whatever system they are happy with and it
> > >> > > doesn't get in the way of deployment/development. Thus this fails
> to
> > >> > > meet one of the critical requirements for consideration for
> inclusion
> > >> > > into core.
> >
> > >> > > D
> >
> > >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <
> baxterstock...@gmail.com> wrote:
> > >> > >> Thanks David, but I'm talking about having something built in.
> For
> > >> > >> instance, passing a variable to the "Development" server to tell
> it
> > >> > >> you're in "Development" seems a bit redundant, no?
> >
> > >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" <
> davidnovako...@gmail.com>
> > >> > >> wrote:
> > >> > >>> As for running different configs:
> >
> > >> > >>> manage.py runserver --settings=settings_test
> >
> > >> > >>> etc..
> >
> > >> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss <
> ja...@jacobian.org> wrote:
> > >> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma <
> baxterstock...@gmail.com> wrote:
> > >> > >>> >> I'm simply proposing the idea of having the development
> server
> > >> > >>> >> explicitly set something to indicate a "in development"
> status, so
> > >> > >>> >> that if that does not exist you can make the assumption that
> the
> > >> > >>> >> project is live.
> >
> > >> > >>> > This is exactly what the settings.DEBUG flag is for. Use it.
> Love it.
> >
> > >> > >>> > Jacob
> >
> > >> > >>> > --
> > >> > >>> > You received this message because you are subscribed to the
> Google Groups "Django developers" 

Error email flooding on high traffic production sites

[Simon Litchfield]

Hi all

Default behaviour of sending an email on 500 error is great.

Problem is on high traffic sites, and you might just be making a quick
update- literally within seconds you can bring your mail server down-
crash your mail client- or render your gmail account useless.

With "batteries included" and "production ready" ethos in mind, I
reckon this needs fixing.

1) Max emails per minute setting

2) Include alternative error handler middleware in core

I haven't tried it yet, but this looks interesting (note web2py
includes this) --
http://bitbucket.org/ashcrow/django-error-capture-middleware/wiki/Home

Thoughts? I know I'm not the only one who has run into this (Russ?)

Cheers
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Actions in popups

[Simon Meers]

Users regularly get confused when you present them with a raw_id popup
window which shows action checkboxes beside the list of items they are
selecting from -- they try to click the checkboxes, and wonder why the
window isn't closing. IMHO it really doesn't make much sense to be
performing actions within the context of a popup selection window anyway,
though I'm no UXpert. A search on trac revealed [1].

Opinions?

[1] http://code.djangoproject.com/ticket/11700

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

#3400 -- ModelAdmin.list_filter improvements

[Simon Meers]

A gentle reminder to anyone who would like to review the recent patch
uploaded for #3400 [1].

I have come across quite a number of people who consider list_filter's
current inability to span relationships (e.g. as search_fields can) to be
one of the more obvious/annoying of Django's limitations and would love to
see it implemented.

[1] http://code.djangoproject.com/ticket/3400

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Why this feature is still not accepted ?

[Simon Meers]

Apart from permissions issues etc as Mikhail mentioned, there is also an
important design decision required about whether it is a good idea to
provide a dynamic link to the selected item rather than the last saved item.
If you allow the user to change their selection and then click the link to
view that item, you're encouraging them to follow a link which will lose
their unsaved changes. I think it is wiser to provide a clear (named) link
to the saved item.

Interesting that this ticket did not come up as a duplicate when #13165 [1]
was opened. I suggest the earlier ticket should be closed as a duplicate,
since #13165 has a more mature/up-to-date patch. It is just awaiting
resolution of permission issues and the input of a UX expert, together with
#13163 [2]

Simon

[1] http://code.djangoproject.com/ticket/13165
[1] http://code.djangoproject.com/ticket/13163


On 7 August 2010 04:46, dharmesh.patel.eif...@gmail.com <
dharmesh.patel.eif...@gmail.com> wrote:

> Hello,
>
> http://code.djangoproject.com/ticket/11397
>
> As I already implemented it for Django version1.1 but still there is
> no action or feedback on it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@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-develop...@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: postgresql last_insert_id issue

[Simon Meers]

The patch here [1] fixes this if anyone feels like reviewing. This bug is
preventing me from using trunk on several projects at present, so it would
be great to get the patch checked in. It also fixes a number of other
problems people have been reporting, I believe.

Simon

[1] http://code.djangoproject.com/ticket/13821


On 29 July 2010 03:19, ryan_peaceworks <thebigsl...@gmail.com> wrote:

> Hi,
>
> I'm running trunk and I found an issue where my model's tablename
> contains uppercase characters.
>
> svn praise says this broke in r13363
>
> r13363   russellm # Use pg_get_serial_sequence to get the
> underlying sequence name
> r13363   russellm # from the table name and column name
> (available since PostgreSQL 8)
> r13363   russellm cursor.execute("SELECT
> CURRVAL(pg_get_serial_sequence('%s','%s'))" % (table_name, pk_name))
>
> The issue is that table_name is not double-quoted when necessary.
>
> Probably the string argument should be self.quote_name(table_name)
> rather than just table_name.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@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-develop...@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: Invalid SQL generated by objects.all()[:1]?

[Simon Riggs]

On Thu, 2010-07-15 at 15:57 -0600, Ian Kelly wrote:
> >
> > It may be that they aren't allowed by the spec, but the only database
> > (that Django includes an adapter for) that doesn't support them
> > (AFAIK) is MySQL.  Further, Event.objects.all()[:1] doesn't generate a
> > subquery at all.
> 
> Er, I'm pretty sure that MySQL does support both ORDER BY and
> LIMIT/OFFSET.  At least, it is documented as supporting them.
> 
> The supported database that does have a problem with LIMIT/OFFSET is
> Oracle.  The backend contains a workaround, which is implemented by a
> custom SQLCompiler in django.db.backends.oracle.compiler, and it
> involves wrapping the original query in a subquery.

> The MonetDB
> backend may be doing something similar, which would explain why that
> query is generating a subquery.

That seems like an explanation for why they mentioned subqueries, though
MonetDB supports LIMIT OFFSET according to their docs.

> All of the internally supported databases support ORDER BY, so I can't
> offer any hints there.

PostgreSQL supports ORDER BY/LIMIT in subqueries, which I believe is an
extension to the SQL standard.

SQL Standard formulation for this query syntax is new in SQL:2008 where
it is now called OFFSET ... FETCH ... To my knowledge only DB2 and
Postgres support the new standard syntax.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Development, 24x7 Support, Training and Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: MySQL index hints

[Simon Litchfield]

Simon --

Slicing result sets is clearly the developer's responsibility IMHO.

Even with hard limits, MySQL still fails miserably in many situations;
hence the proposal to support hinting from the ORM.

Russ --

Firstly, re namespacing. No worries, let's just keep it RDBMS-
specific, ie --

MySQL - with_hints(use={}, force={}, ignore={})
Oracle - with_hints(index={}, ...)

That gives plenty of name space to breathe in.

Next --

> Using the filter/exclude name sounds interesting, but skips the first
> step of putting an index hint on the origin table. For example,
> Book.objects.filter(author__name='foo') -- now put an index hint on
> Book; now put one on Author. If Author and Book are an a m2m relation
> -- put a hint on the m2m table.

How about --

  {'book': 'book_idx', 'author': 'author_idx', 'author__name':
'm2m_idx'}

Or, if you want to cover absolutely every possibility --

  {'book': 'book_idx', 'author__name__author': 'author_idx',
'author__name': 'm2m_idx'}

That is, require indexes on the right side of joins to be named
explicitly, just in case Author is used in another join.

Sounds complicated, but obviously edge case. Common usage will be
simple, eg {'book':'book_idx'}.

Let me know what you think.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: natural keys and dumpdata

[Simon Meers]

> I'll put it on my todo list; if anyone else wants to give it a sanity
> check, I'd appreciate the extra eyeballs.

Looks pretty sane to me, though I wonder if the deserialisation should
raise an exception if the pk is missing and an incomplete set of
natural key fields is provided? Nice work, thanks Chris.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: MySQL index hints

[Simon Riggs]

On Mon, 2010-07-05 at 00:59 -0700, Simon Litchfield wrote:
> > If you can come up with answers to these points, I might get
> > interested. 1 and 2 are fairly trivial; I can think of some obvious
> > answers for 3, but 4 is the big problem, and will require some
> serious
> > research and consideration.
> 
> Well, I'm glad you like the with_hints() approach. Items 1-3 are easy.
> Re 4 though, every db does it differently. In practice, most don't
> need hints like MySQL does , because their query optimisers do a
> much better job.

The big problem I see is that hints are simply the wrong approach to
handling this issue, which I do see as an important one.

The SQL optimizer can't work out how you're going to handle the queryset
if all you mention is the filter(). SQL being a set-based language the
optimizer won't know whether you wish to retrieve 0, 1 or 1 million
rows. In many cases it actively avoids using the index for what it
thinks will be larger retrievals.

The number of rows required from the queryset is an important part of
defining the access path. Hints are only required because we didn't
specify the queryset in sufficient detail for the optimizer to
understand what we wanted.

I would say the correct approach here is to use slicing, since this will
add a LIMIT clause and provide full usage information to the SQL
optimizer about the queryset.

Can I suggest an auto-slice parameter so that we can add LIMIT N onto
the bottom of every query by default, if a slice is not already defined.
That would work for all DBMS.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Development, 24x7 Support, Training and Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Digest for django-developers@googlegroups.com - 16 Messages in 5 Topics

[Simon Lambert]

On 6 Jul 2010, at 04:45, django-developers+nore...@googlegroups.com  
wrote:



  Today's Topic Summary
Group: http://groups.google.com/group/django-developers/topics

Spam attack on the Wiki [2 Updates]
Django Developers needed for Start-up Long Island, NY [1 Update]
MySQL index hints [7 Updates]
documentation re-factor for 1.3? [3 Updates]
Django and the Eyjafjallajökull eruption [3 Updates]
 Topic: Spam attack on the Wiki
Christopher Petrilli <petri...@amber.org> Jul 05 12:18PM -0400 ^

Just an FYI, but there's been hundreds of edits to add spam links in
the last few hours. Might be worth locking it and rewinding the
database.

Chris
--
| Chris Petrilli
| petri...@amber.org


Alex Gaynor <alex.gay...@gmail.com> Jul 05 12:13PM -0500 ^

I just went through and deleted all of his edits.

Alex

On Mon, Jul 5, 2010 at 11:18 AM, Christopher Petrilli

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me


 Topic: Django Developers needed for Start-up Long Island, NY
Norm Levy <norml...@mediastreetgroup.com> Jul 05 11:29AM -0400 ^

Do you know any Djangonaughts that are in the Long Island or New  
York area

that may be interested in Part Time or Full Time work?

I am in need of some Django developers for my upstart we created  
a few

web platforms using Django.

http://ShoutOmatic.com - audible Tweet
http://LifeGoRound.com - social-photo aggregator that sends your  
online

content to your digital photo frame.

Thank you for any guidance ... or suggestions

.. Working Remotely may be OK as well we need a minimum of 4 to  
5 hours

a day.

Equity-stake in the new Start-up is also part of the dicsussion

Norm Levy

---

http://MediaStreetGroup.com


 Topic: MySQL index hints
hinnack <henrik.gens...@miadi.net> Jul 05 12:08AM -0700 ^

Thats interesting.
Can you explain, how the search keyword made it into the source?
Entry.objects.filter(headline__search="+Django -jazz Python")
SELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz
Python IN BOOLEAN MODE);
Seems to be very MySQL specific...

regards

Henrik




Simon Litchfield <si...@slicmedia.com> Jul 05 12:59AM -0700 ^

> interested. 1 and 2 are fairly trivial; I can think of some obvious
> answers for 3, but 4 is the big problem, and will require some  
serious

> research and consideration.

Well, I'm glad you like the with_hints() approach. Items 1-3 are easy.
Re 4 though, every db does it differently. In practice, most don't
need hints like MySQL does , because their query optimisers do a
much better job.

I'd be happy to use raw(); but then you lose len(), slicing,
pagination, filter chaining, etc. My problem came about because admin
change lists were unusably slow on large tables. With_hints allowed a
simple monkey patch to admin, dropping 2s per page down to ~0.01s.

MySQL is still the most used backend AFAIK, and it's the one that
really needs the hints (poor old thing it is). Adding with_hints()
will only serve to encourage support from other backends too, where
possible.

Maybe we can make the with_hints() syntax more generic with both
common and backend-specific kwargs --

.with_hints(index='my_index') (string implies index on queryset base
model)
.with_hints(index={Model:'my_index', RelatedModel:'index2'})
(dictionary allows defining index on a per-model basis)

So the Oracle backend, for example, could implement --

.with_hints(hash=True, index={Model:'my_index',
RelatedModel:'index2'}) (

On Oracle there are dozens of possible hints, so I'd say unsupported
kwargs could simply be ignored. This would ensure seamless database
portability.


Simon Litchfield <si...@slicmedia.com> Jul 05 01:01AM -0700 ^

> SELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz
> Python IN BOOLEAN MODE);
> Seems to be very MySQL specific...

Yes Henrik, it's true- this is a classic example of a *very useful*
MySQL-specific feature already in the ORM.


Luke Plant <l.plant...@cantab.net> Jul 05 01:11PM +0100 ^

On Mon, 2010-07-05 at 00:59 -0700, Simon Litchfield wrote:

> pagination, filter chaining, etc. My problem came about because  
admin
> change lists were unusably slow on large tables. With_hints  
allowed a

> simple monkey patch to admin, dropping 2s per page down to ~0.01s.

So the underlying problem is: how to rewrite a query (whether  
generated

by my code, someone else's code, or a mixture) so that it performs
better on my database. There will always be third party code which
generates queries that are really bad for performance, depending on  
your

project or your database. This also applies to tickets like
http://code.djangoproject.com/ticket/11604

This makes me think that what we need is a mechanism to do an  

Re: MySQL index hints

[Simon Litchfield]

> I would like to know how you're validating your assertion that MySQL
> is the most used backend. It doesn't match my experience or
> observation.

Nobody knows for sure. I'd put my money on it though.

> The fact that this is a MySQL-specific issue is perhaps the biggest
> impediment to my enthusiasm about this specific feature (as proposed).
> I've spent enough time in the past covering for the inadequacies of
> MySQL. I don't particularly relish the thought of adding more time to
> that particular ledger. :-)

I know, I've seen you pulling your hair out :-)

> Having an implementation ignore kwargs is the obvious approach to
> providing this feature cross platform. The issue for me is what
> exactly the kwargs should be, and how they would be interpreted. It
> isn't clear to be how 'index="my_index"' maps to the application of
> USE INDEX, IGNORE INDEX or FORCE INDEX in a query, or how the
> dictionary syntax would map to the situation where you have two
> appearances of a given table in a query.

Great, so lets define the syntax then and away we go.

1) I'd say index= would map to MySQL's USE INDEX and Oracle's index().
The others you mention there would be MySQL-specific kwargs. Or, more
simply, ignore and force could be '-index' and '+index'. Bit like we
use + and - for order_by.

2) The multiple table issue is edge case but worth supporting if it
doesn't complicate the syntax too much. Rather than use models as keys
we could use the filter/exclude name; eg {'relatedmodel__field':
'index'} would apply 'index' specifically to the 'relatedmodel__field'
join.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: MySQL index hints

[Simon Litchfield]

On Jul 5, 5:08 pm, hinnack  wrote:
> Thats interesting.
> Can you explain, how the search keyword made it into the source?
> Entry.objects.filter(headline__search="+Django -jazz Python")
> SELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz
> Python IN BOOLEAN MODE);
> Seems to be very MySQL specific...

Yes Henrik, it's true- this is a classic example of a *very useful*
MySQL-specific feature already in the ORM.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: MySQL index hints

[Simon Litchfield]

> If you can come up with answers to these points, I might get
> interested. 1 and 2 are fairly trivial; I can think of some obvious
> answers for 3, but 4 is the big problem, and will require some serious
> research and consideration.

Well, I'm glad you like the with_hints() approach. Items 1-3 are easy.
Re 4 though, every db does it differently. In practice, most don't
need hints like MySQL does , because their query optimisers do a
much better job.

I'd be happy to use raw(); but then you lose len(), slicing,
pagination, filter chaining, etc. My problem came about because admin
change lists were unusably slow on large tables. With_hints allowed a
simple monkey patch to admin, dropping 2s per page down to ~0.01s.

MySQL is still the most used backend AFAIK, and it's the one that
really needs the hints (poor old thing it is). Adding with_hints()
will only serve to encourage support from other backends too, where
possible.

Maybe we can make the with_hints() syntax more generic with both
common and backend-specific kwargs --

.with_hints(index='my_index')  (string implies index on queryset base
model)
.with_hints(index={Model:'my_index', RelatedModel:'index2'})
(dictionary allows defining index on a per-model basis)

So the Oracle backend, for example, could implement --

.with_hints(hash=True, index={Model:'my_index',
RelatedModel:'index2'})(

On Oracle there are dozens of possible hints, so I'd say unsupported
kwargs could simply be ignored. This would ensure seamless database
portability.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

MySQL index hints

[Simon Litchfield]

For those of us using MySQL, having large tables, whilst also wanting
queryset goodness --
http://code.djangoproject.com/ticket/11003

It goes a little something like this --
Model.objects.filter(field=value).with_hints('my_index')

All those in favour say I.

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature Request

[Simon Meers]

On 22 June 2010 19:59, Massimiliano della Rovere <
massimiliano.dellarov...@gmail.com> wrote:

> Anyway using this method I can't sort columns any more.
> This is why I was suggesting having links created by the framework:
> callable aren't sortable.
>

They can be -- set admin_order_field on the callable [1]

[1]
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature Request

[Simon Meers]

On 21 June 2010 17:49, Massimiliano della Rovere
 wrote:
> If I understood correctly, these patches are related to the change view of
> the instance, not to che change list view (the page where instances are
> listed).

Correct; I interpreted your request for "the change page of the linked
object" to be the "change" page for the instance, not the "changelist"
for the model.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature Request

[Simon Meers]

> EmailField, UrlField, Foreign Key, OneToOneField and ManyToManyField
> clickable in the admin changelist interface of Django 1.3:
> if you click you are redirected to:
>  - Foreign Key, OneToOneField and ManyToManyField: the change page of
> the linked object

This is already implemented in the patch for #13163 [1] and #13165 [2]
(though ManyToMany seemed a bad idea). Plus screenshots [3].

[1] http://code.djangoproject.com/ticket/13163
[2] http://code.djangoproject.com/ticket/13165
[3] http://share.simonmeers.com/django_related_changelinks/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 Related-Object Links in Admin

[Simon Meers]

>>  * Permissions - from my initial inspection, it isn't obvious to me
>> that you are honoring (and/or testing that you are honoring)
>> permissions. If I don't have permission to edit an object, I shouldn't
>> get an edit link. Given the addition in 1.2 of object-level
>> permissions, this means permissions need to be per-object. Have I
>> missed something in my hasty patch read?
>
> Correct; no permissions checking is performed at present. In some
> places checking would be almost impossible given the current code
> architecture, so I had hoped to avoid it if possible. This was one of
> the main points I wanted feedback on.

Here is a more detailed explanation of why permission checking has
been omitted for now:

* The "add-another" link (green plus) next to ForeignKey widgets is
appended to the HTML output in the render() method. This currently has
no access to the User, so cannot determine permissions. The
"add-another" link (and new "edit" link) will therefore be displayed
regardless of the current user's add/change permissions for the
related object. This should certainly be dealt with, but this ticket
does not appear to the the appropriate place to do so. Ticket #1035
[1] addresses this issue.

* The "edit separately" links on inlines could perform checking using
a templatetag, perhaps. Again, however, I'm not sure that this is the
place to deal with this as larger issues exist -- currently a user can
add/change inlines even if they do not possess permissions for the
inline model. Ticket #8060 [2] addresses this issue.

So the current patch for #13163 and #13165 [3] seems to solve the
issues in a manner which fits with the rest of the admin interface as
it currently stands. Permission issues should certainly be dealt with,
but separately I believe. I think [3] could be committed as is
(pending review), and permission controls added as the other tickets
are resolved. Currently all this means is that people might see an
edit link, click on it, then get a "permission denied" message --
though in the relatively rare cases where a related object is
registered in the same admin site but the user doesn't have permission
to change it.

IMHO the UX improvements in [3] are worth getting on board ASAP.

Simon


[1] http://code.djangoproject.com/ticket/1035
[2] http://code.djangoproject.com/ticket/8060
[3] 
http://code.djangoproject.com/attachment/ticket/13163/combined_13163_13165.diff

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Decision required: PostgreSQL minimum versions

[Simon Riggs]

On Thu, 2010-06-10 at 22:29 +0800, Russell Keith-Magee wrote:

> There appears to be some confusion here. We're not recommending a
> version of PostgreSQL that end-users should use; we're nominating the
> minimum possible version that passes Django's test suite. PostgreSQL
> 7.4 may be bad for all sorts of reasons, but right now, all the
> features of PostgreSQL that Django uses utilize are available in
> PostgreSQL 7.4. When the fix for #8901 lands, this raises the bar to
> PostgreSQL 8.0, but only because of the use of
> pg_get_serial_sequence().
> 
> I completely agree that users would be well advised to upgrade to
> PostreSQL 8.4, and there are many reasons beyond basic Django
> compatibility that should drive that upgrading process. However, that
> doesn't change the fact that from a purely functional perspective,
> Django will work happily on PostgreSQL 8.0 (unless you want to use
> database-level autocommit or savepoints, in which case the minimum
> version is 8.2).

I take your point about the differences.

In this case, the PostgreSQL project is just about to de-support those
release levels, so that does change things somewhat. I'm not sure why it
would be useful for a future version of Django to advertise support for
a PostgreSQL version that the PostgreSQL project is itself intending to
de-support. That seems likely to cause disappointment, even though you
are correct and it will pass tests.

I am just the messenger in this, carrying goodwill between projects.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Development, 24x7 Support, Training and Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Decision required: PostgreSQL minimum versions

[Simon Riggs]

On Thu, 2010-06-10 at 13:41 +0400, reg...@messir.net wrote:
> For old postgress we have old django. So, do not hesitate kicking off
> old code. Even 8.2 version is very-very old so it's okay to depend on
> 8.2+.
> 
> > While we support PostgreSQL, our documentation doesn't actually
> > specify a minimum supported version. We have a couple of features that
> > are no-ops for versions prior to 8.2 (savepoints and database
> > autocommit), but we don't actually document a minimum required
> > version.

(Re-post, first post stalled)

Yeh, Django should really be moving to PostgreSQL 8.3 or above, because
of performance, administrative ease and availability of replication
features.

PostgreSQL 7.4 and 8.0 are due to be de-supported in about 1 month, 8.1
is due for de-support by end of 2010. (8.0 and 8.1 have already been
de-supported on Windows). So 8.2 is the minimum sensible version for
next release of Django, though 8.3 should be minimum recommended with
8.4 current stable release as dev target.

Happy to help with any issues arising from that move.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Development, 24x7 Support, Training and Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 patches

[Simon Meers]

Hi Sebastian,

> Btw, running the test suite with mysql takes forever.
> If you know the reason please tell me. However i was able to run the
> test suite on a plain django 1.2.1 installation with sqlite, but got 11
> failures and 37 errors ...

Have you read [1]? Do you still get errors if you run:
./runtests.py --settings=test_sqlite
from the tests/ directory?

Did you also know you can run any desired subset of tests? E.g.:
./runtests.py --settings=test_sqlite admin_inlines admin_views
--
Ran 145 tests in 29.500s

Simon

[1] 
http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 Related-Object Links in Admin

[Simon Meers]

> The demo screenshots you provide certainly look good to me; I haven't
> done a full teardown on the patch, but a from a quick glance it
> certainly looks promising.

Thanks for your response Russ.

>  * Why allow edit links on a readonly field? This seems a little
> redundant to me?

Because whilst the field on that model might be read-only, the related
object itself is not necessarily. In fact in most cases I've found
that this is the case.

>  * On the edit link for ForeignKey (localhost:8000 in your example),
> I'd be inclined to stick to just "edit", not "edit " -- that
> seems more consistent with the other edit links you have provided.

But then if you select a different object, "edit" looks like it refers
to the selected one instead of the original. I could have used
JavaScript here to select the dynamically chosen object, but in the
absence of a popup link this would be pointless -- you choose a
different ForeignKey value, then leave the page to edit it thinking
you've saved the value...

>  * I take it that the widget edit links carry through to inlines?
> i.e., if i have a foreign key pulldown in an inline, I will get the
> edit link?

Yes.

>  * How does performance degrade when JavaScript is not available? Do
> the links exist at all, or do they become dangling links to the wrong
> object?

Solid as a rock; does not use JavaScript.

>  * In the case of raw-id fields and inlines, is there any reason why
> the edit link is separate text, rather than the object name itself
> being the link? (ie., rather than "John smith ", why
> not just ""?

Yes; because you're already editing John smith, but if you want to
edit him separately you can go elsewhere to do so with a (probably
more detailed) dedicated form.

>  * Permissions - from my initial inspection, it isn't obvious to me
> that you are honoring (and/or testing that you are honoring)
> permissions. If I don't have permission to edit an object, I shouldn't
> get an edit link. Given the addition in 1.2 of object-level
> permissions, this means permissions need to be per-object. Have I
> missed something in my hasty patch read?

Correct; no permissions checking is performed at present. In some
places checking would be almost impossible given the current code
architecture, so I had hoped to avoid it if possible. This was one of
the main points I wanted feedback on.

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 Related-Object Links in Admin

[Simon Meers]

On 25 May 2010 07:50, Simon Meers <drme...@gmail.com> wrote:
>
> I've uploaded some screenshots [1] of the new patch for #13163 [2] and
> #13165 [3] in action, to allow people to see the affect without
> necessarily applying the changes.
>
> These enhancements have *vastly* improved the navigability of the
> admin interface between related objects.
>
> Please have a look and let me know if you have concerns or suggestions
> for improvement. The design decisions are documented in the tickets.
>
> [1] http://share.simonmeers.com/django_related_changelinks/
> [2] http://code.djangoproject.com/ticket/13163
> [3] http://code.djangoproject.com/ticket/13165


I'm guessing DjangoCon.eu week wasn't the ideal time to send this.
Loads of people did check the screenshots out though. Anyone have
concerns or suggestions?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: www.djangoproject.com down?

[Simon Meers]

http://downforeveryoneorjustme.com/djangoproject.com

On 1 June 2010 17:23, Vinay Sajip  wrote:

> I've been having trouble accessing www.djangoproject.com recently,
> from here in the UK. Is this a known problem? Is the server down?
>
> Regards,
>
> Vinay Sajip
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

#11882 Ready for checkin?

[Simon Meers]

I was today momentarily caught out by the missing documentation for
formfield_for_manytomany, and found #11882 [1] which has a patch for
this very issue and was marked "Ready for checkin" last year. It's a
shame it missed 1.2 Anyone care to give it a push?

[1] http://code.djangoproject.com/ticket/11882

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Django Related-Object Links in Admin

[Simon Meers]

I've uploaded some screenshots [1] of the new patch for #13163 [2] and
#13165 [3] in action, to allow people to see the affect without
necessarily applying the changes.

These enhancements have *vastly* improved the navigability of the
admin interface between related objects.

Please have a look and let me know if you have concerns or suggestions
for improvement. The design decisions are documented in the tickets.

[1] http://share.simonmeers.com/django_related_changelinks/
[2] http://code.djangoproject.com/ticket/13163
[3] http://code.djangoproject.com/ticket/13165

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Trac Full!

[Simon Meers]

> I was trying to figure out why I was getting Internal Server Errors
> when attempting to upload a patch on code.djangoproject.com -- I have
> discovered that there is "no space left on the device"!

This seems to be fixed now (thank you webmaster). However it may be
worth noting that the email address on the 500 message is apparently
invalid:

Delivery to the following recipient failed permanently:

webmas...@djangoproject.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.1.1
: Recipient address rejected: User
unknown in local recipient table (state 14).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Trac Full!

[Simon Meers]

I was trying to figure out why I was getting Internal Server Errors
when attempting to upload a patch on code.djangoproject.com -- I have
discovered that there is "no space left on the device"!

Now you can't even add a comment to the database:

Traceback (most recent call last):
  File "/home/trac/trac/web/main.py", line 406, in dispatch_request
dispatcher.dispatch(req)
  File "/home/trac/trac/web/main.py", line 237, in dispatch
resp = chosen_handler.process_request(req)
  File "/home/trac/trac/ticket/web_ui.py", line 290, in process_request
self._do_save(req, db, ticket)
  File "/home/trac/trac/ticket/web_ui.py", line 558, in _do_save
cnum=internal_cnum):
  File "/home/trac/trac/ticket/model.py", line 250, in save_changes
(self.id, when, author, cnum, comment))
  File "/home/trac/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
  File "/home/trac/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
ProgrammingError: could not extend relation 1663/24784/3185145: No
space left on device
HINT:  Check free disk space.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Display link to change-form on inlines where model is registered in admin site

[Simon Meers]

I've just submitted #13163 [1] with a patch to display a link to the full
change-form for inlines of models which are registered in the same admin
site, similar to the existing "view on site" link for inlines. I have had
numerous projects where this would have been immensely useful (for which I
had to create hacked copies of the full inline templates).

I know we're in 1.2 bugfix, so feel free to leave this until later.
Otherwise:
- Is this change useful/minor enough to include in 1.2?
- Does anyone know of cases where this behaviour should be disabled (see
ticket)?

Simon

[1]: http://code.djangoproject.com/ticket/13163

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Bug in Form metaclass?

[Simon Meers]

Thanks for looking into this Russ

> Firstly, django-dev isn't "second tier tech support" - if you don't
> get an answer on django-users for a user-space question, that's a
> pity, but it doesn't mean you can or should "escalate" to django-dev.

I realise this; I thought this was the place to discuss potential
bugs, but thought I'd better throw some sanity checks out elsewhere
before I did.

> Doesn't look like a bug. Subclassing AuthenticationForm works for me,
> and I can't find any way to make your test case fail in the way you
> describe.

I thought I was going crazy when I tried again just now and couldn't
reproduce it myself! Thankfully I tracked the problem down to
importing django via a symlink in the project directory to the
appropriate version. If I remove the symlink and let it import django
from elsewhere in the pythonpath, it works as expected.

$ cat test.py
from django.contrib.auth.forms import AuthenticationForm
from django import forms

class MyForm(AuthenticationForm):
extra_field = forms.BooleanField()

print MyForm().fields.keys()
$ ./manage.py validate
['username', 'password', 'extra_field']
0 errors found
$ ln -s /media/d/Development/django/django-trunk/django/
$ ./manage.py validate
['username', 'password']
0 errors found

Odd. I've never encountered any other problems when using a local
symlink to django; everything else seems to operate fine.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Bug in Form metaclass?

[Simon Meers]

Disclaimer: Just in case this was a naive mistake on my part, I posted
this on django-users first [1] and posed the question several times on
#django, but have received no answers.

#
# forms.py:
#
    from django import forms
    class TestForm(forms.Form):
        test_field = forms.BooleanField()
#

#
# test.py:
#
    # import the same class from two different locations:
    from project_name.forms import TestForm
    from project_name.some_module.forms import TestForm as TestForm2

    class MyForm(TestForm):
        extra_field = forms.BooleanField()

    print MyForm().fields.keys()
    # prints: ['test_field', 'extra_field'] as expected

    class MyForm2(TestForm2):
        extra_field = forms.BooleanField()

    print MyForm2().fields.keys()
    # prints: ['test_field']
    # extra fields not registered if superclass imported from other app/module!
#

Python 2.6.4, Django SVN-12401

Is this a bug? The same happens if you try to import, say,
django.contrib.auth.forms.AuthenticationForm and subclass it. Surely
I'm missing something here?

Simon

[1] 
http://groups.google.com/group/django-users/browse_thread/thread/b4b4ddd684b352e1

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Suggestion: DictionaryField

[Simon Meers]

I had considered designing something like this last week. It does seem to be
a common requirement -- any situation where a simple field would be almost
suitable but for the fact you'd like to avoid duplicates and allow fast
selection of existing values. A Field shortcut could be commonly used to
avoid the creation of separate models. Another example:

class Suburb(models.Model):
name = models.CharField(max_length=64, unique=True)

class Meta:
ordering = ['name']

def __unicode__(self):
return u'%s' % self.name


class School(models.Model):
name = models.CharField(max_length=64, unique=True)

class Meta:
ordering = ['name']

def __unicode__(self):
return u'%s' % self.name


class Student(models.Model):
school = models.ForeignKey(School)
suburb = models.ForeignKey(Suburb)
# ...

could be replaced with simply:

class Student(models.Model):
school = models.DictionaryField(max_length=64)
suburb = models.DictionaryField(max_length=64)
# ...

I'm not 100% sold on the name, but I think it is on the right track. I'm
also wondering whether it could be worth catering for types other than
CharField as well. For example:

team_number = models.DictionaryField(type=models.IntegerField)

This makes me wonder whether perhaps this could be generically applied to
all fields via a Field.__init__ kwarg instead:

class Student(models.Model):
school = models.CharField(max_length=64, lookup=True)
suburb = models.CharField(max_length=64, lookup=True)
team_number = models.IntegerField(lookup=True)

Either way, these fields could then be stored in separate tables
appname_modelname_fieldname, with a single field of the appropriate type
(named 'value' or similar). It would be nice to also provide external access
to these auto-generated models via something like Student.school.objects.
Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
and objects can be accessed via
Student.school.field.related.parent_model.objects.all(), but a shortcut
would be nice.

The auto-generated models could provide ordering by value, a unique
constraint on the field, and a simple __unicode__ method like the examples
above.

Simon


2010/1/17 Михаил Лукин <mihail.lu...@googlemail.com>

> Well, the simplest way is making DictionaryField more like CharField,
> except that it's values will be stored in separate table. For example
> (application name is "hardware", engine is sqlite3), if I define
>
> *class HDD(models.Model):
>   form_factor = DictionaryField(max_length=10)
>   capacity = models.FloatField()
> *
> there will be 2 tables generated:
>
> *CREATE TABLE "hardware_hdd_form_factor_dict" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor" varchar(10) NOT NULL UNIQUE
> )
> CREATE TABLE "hardware_hdd" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor_id" integer NOT NULL REFERENCES
> "hardware_hdd_form_factor_dict" ("id"),
> "capacity" real NOT NULL
> )
>
> * I guess, field constructor should not accept "unique" argument as it
> make no sense.
> I see 2 ways of rendering such field on a form:
> 1) usual  with autocompletion;
> 2)  +  + (maybe) radio buttons
> as it should be allowed to choose from existing and to create new
> dictionary item.
>
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@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: Logging format decision

[Simon Willison]

On Jan 14, 1:57 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> The other issue that I think still needs to be addressed is the
> internal usage of logging by Django itself.

My biggest hangup with the logging implementation was figuring out
exactly when the logging configuration code should actually run. The
problem is that Django's startup execution order is poorly defined -
stuff relating to settings is lazily evaluated the first time it's
needed, and there's no real documented place to put code that needs to
be executed once (the fact so many registration things end up being
called from urls.py is a good indicator that this is a problem).

This has put me off using signal handlers in my own code in the past,
and it also came up with the logging work.

I think Django needs a defined and documented execution order on
startup. I'm not entirely clear why we've avoided this in the past -
I've read http://www.b-list.org/weblog/2007/nov/05/server-startup/ but
it hasn't convinced me that a defined startup order for things like
registration patterns, signal handlers, logging configuration is a bad
thing.

Personally, I'd like to see this happen as part of the instantiation
of a single Django "site object" which handles all requests to the
server. We almost do this at the moment - if you look at the code in
http://code.djangoproject.com/browser/django/trunk/django/core/handlers/
each handler basically instantiates an object once which then has its
get_response() method called for every incoming request. Unfortunately
the time at which this object is instantiated seems to be pretty ad-
hoc - how and when it happens depends on if you're running under WSGI,
mod_python or the development server.

Defining Django's execution order is a pretty big job, but it would be
a great thing to achieve for 1.3. The obvious thing to tie it to would
be INSTALLED_APPS - it could be as simple as having an API promise
that the first thing Django does when it "starts" is to run through
each application in INSTALLED_APPS looking for and importing an
autoload.py module. I imagine we'll find that the time at which models
are registered is critical (what if autoload.py wants to use a model
that hasn't been loaded in to the AppCache yet?) and may need to do
more than one pass through INSTALLED_APPS. Plenty of details to figure
out.

Cheers,

Simon
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Model validation incompatibility with existing Django idioms

[Simon Willison]

A couple of related tickets filed today about model validation:

http://code.djangoproject.com/ticket/12513
http://code.djangoproject.com/ticket/12521

The first one describes the issue best - the new model validation code
breaks the following common Django convention:

form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
if form.is_valid():
p = form.save(commit=False)
p.user = request.user
p.primary_contact = somecontact
p.save()

The problem is that is_valid() notices that some of the required
fields in SecretQuestionForm (a ModelForm) have not been provided,
even if those fields are excluded from validation using the excludes=
or fields= properties. The exception raised is a
UnresolvableValidationError.

This definitely needs to be fixed as it presumably breaks backwards
compatibility with lots of existing code (it breaks a common
ModelAdmin subclass convention as well, see #12521). Can we just
change the is_valid() logic to ignore model validation errors raised
against fields which aren't part of the ModelForm, or is it more
complicated than that?

Cheers,

Simon
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Design and code review requested for Django string signing / signed cookies

[Simon Willison]

On Jan 4, 6:18 pm, James Bennett <ubernost...@gmail.com> wrote:
> Simon, the amount of pushback this is getting, and the changes which
> need to be made to start bringing it up to snuff, make me feel far too
> nervous about this being ready in time to make 1.2 at all. I know
> you've put in the effort to shepherd this along, but I'm starting to
> think it's time to push this to the 1.3 release cycle (especially
> since 1.2 alpha freeze is tomorrow, and I don't think there's any way
> it'll be even alpha-ready by then).

I certainly don't think we should check this in for the alpha freeze.

We do however need to consider the places in Django that are already
using hmac / md5 / sha1 (contrib.formtools and middleware.csrf for
example). Even if we don't add the signed cookies feature to 1.2,
fixing any problems with our existing use of crypto should not be
affected by the feature freeze. There's not much point in implementing
this logic in several different places, so I think we should keep
targeting the django.utils.signed module for 1.2.

Cheers,

Simon

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Design and code review requested for Django string signing / signed cookies

[Simon Willison]

On Jan 4, 2:45 pm, Jordan Christensen  wrote:
> Is there a good way to make it forward upgradeable? Allow the
> developer to decide on the shorter SHA-1 hash or the (theoretically)
> more secure SHA-256?

There is - we can expand the BACKEND setting which is already in place
for signed cookies (but not for other clients of the Signer class). I
think we should do this. For one thing, it would mean we could provide
a backend which uses the Google keyczar Python library instead of the
code that we write. keyczar is properly audited, but depends on
PyCrypto so isn't appropriate as a required dependency of Django.

Another thing we can do is use SHA-256 but truncate the HMAC to 128
characters. Apparently it's perfectly fine to do this - it's being
discussed in the programming.reddit thread at the moment.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.