date:20150211

Re: [Django] #24215: Refactor of lazy model operations

2015-02-11 Thread Django

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by AlexHill):

 Incidentally, what do you think of #21175 - having abstract models fire
 class_prepared?

 I'm thinking that in keeping with what we're talking about here, maybe
 they shouldn't.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.86ed0a539b629b7b2a20a3fa21380451%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24215: Refactor of lazy model operations

2015-02-11 Thread Django

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by AlexHill):

 Yep, after my last post in django-developers I basically did the same
 thing as you in my pull request, just hadn't updated this ticket yet
 
([https://github.com/AlexHill/django/commit/3e7b896617a9fe1f315b757a45f92a58d707575f
 see commit here]). Good to see we're thinking along the same lines.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7e0f932c3b7418d3a30ecb310766%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24215: Refactor of lazy model operations

2015-02-11 Thread Django

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 As pointed out by Carl on the mailing list abstract model should only be
 considered as field and method placeholders.

 The real issue here is related fields declared on abstract models that add
 themselves to the apps `_pending_lookups`.

 See [https://github.com/django/django/pull/4115 this PR].

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.beec43568f70f4cc7c0de181f89ed2c9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23697: Confusing exception raised upon unknown field in queryset filter argument

2015-02-11 Thread Django

#23697: Confusing exception raised upon unknown field in queryset filter 
argument
-+-
 Reporter:  mbertheau|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 #23351 was a duplicate which manifested itself in the admins
 `search_fields` references.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.dae60c33492c6bf02603e8fa5fda6fc3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23351: Admin Search Field error for related lookup

2015-02-11 Thread Django

#23351: Admin Search Field error for related lookup
-+-
 Reporter:  ebertti  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * status:  new => closed
 * type:  Bug => Cleanup/optimization
 * resolution:   => duplicate


Comment:

 Thanks for the report but let's keep this ticket closed by marking it as a
 duplicate instead and move all discussion to #23697.

 The fix suggested by Tim on #23697 should prevent reports similar to this
 one which were probably caused by a simple typo in the field name.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c96ccfafbe2696604f9ea1d2f842e1e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24171: (1054, "Unknown column '__col1' in 'field list'") when using values, annotate and aggrregate

2015-02-11 Thread Django

#24171: (1054, "Unknown column '__col1' in 'field list'") when using values,
annotate and aggrregate
-+-
 Reporter:  abdulhaq-e   |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * owner:  nobody => jarshwah
 * needs_better_patch:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 The full traceback would have been useful, but from a cursory glance this
 error is a bug. If you could put together a minimal test case I'll work on
 reproducing and seeing what can be done about it.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.082d858aaee24b073d2bcc83c00a590c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

2015-02-11 Thread Django

Comment (by charettes):

I agree with Josh that we should provide early validation when we can
easily do it.

The simplicity of the patch convince me we should go forward with fixing
this.

On a side note I think that if the
[https://docs.python.org/3.3/library/ipaddress.html ipaddress] module had
been part of the all the supported Python version stdlib when the
`GenericIpAddressField` was added it would have raised a `ValueError`
instead of a database one.

Since the `uuid` module is part of the stdlib I think it would be more
fair to compare the `UUIDField`'s behavior to the temporal ones backed by
the `datetime` module.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.83c782efb81c784fcb9173e154c1fe42%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

2015-02-11 Thread Django

Comment (by jarshwah):

I agree with Tim that get_x_prep is not required to do validation on
values coming in. The methods are responsible for converting data to a
format that the database accepts. This happens to naturally validate some
model fields during the conversion - but this is a side effect.

However, when it is easy enough to provide validation we should. The error
messages are usually clearer to read, and we prevent an entire class of
wrong data ever getting to the database. Fail fast etc.

I've knocked out a quick patch to fix this as I think the change is nice
and localised. See https://github.com/django/django/pull/4114

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.fed38b3168ff9e62f1f62dfde541ce96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

2015-02-11 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"a6ea62aeafd4512f6d13aeda908f7622776a4537"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a6ea62aeafd4512f6d13aeda908f7622776a4537"
 [1.8.x] Refs #14030 -- Improved expression support for python values

 Backport of e2d6e14662d780383e18066a3182155fb5b7747b from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.613936e838cf22a1c2cee06c82fc895f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

2015-02-11 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"e2d6e14662d780383e18066a3182155fb5b7747b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2d6e14662d780383e18066a3182155fb5b7747b"
 Refs #14030 -- Improved expression support for python values
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.276d162ee7295eb19d97536ad5e786dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24289: Is usage of many_to_one and one_to_many terms confusing for relation flags?

2015-02-11 Thread Django

#24289: Is usage of many_to_one and one_to_many terms confusing for relation 
flags?
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 I'm more in favour of using different terminology, though I don't have any
 suggestions on what might be 'better'.

 I had justified the status quo somehow when we discussed this on IRC
 awhile back, but I can't justify it anymore. The proposed change makes
 sense.

 ForeignKey = many_to_one
 ReverseRel = one_to_many

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.532c59be247704fd0353d59f87b8ec49%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

2015-02-11 Thread Django

#24319: UUIDField do not properly clean (validate) value in get_db_prep_value
-+-
 Reporter:  davidfischer-ch  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  clean,uuid   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I am not sure the contract for `get_prep_value()` says that it will
 prevent queries for invalid values like you've stated. Is there any
 documentation to support that assertion? A similar error can be trigger on
 other fields:
 {{{
 >>> GenericIPAddress.objects.filter(ip='baz')
 DataError: invalid input syntax for type inet: "baz"
 LINE 1: ...ess" WHERE "model_fields_genericipaddress"."ip" = 'baz'::ine...
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.8956592493320cf4b9a91c161f125d87%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24161: Using UUIDField for id of custom User model prevents logging in

2015-02-11 Thread Django

#24161: Using UUIDField for id of custom User model prevents logging in
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  1.8alpha1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


Comment:

 Tim's patch LGTM.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.933b70fca1a924665ec36588cb8ca0dc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format

2015-02-11 Thread Django

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  1.8alpha1
  (Serialization)|
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I created a custom user with UUID pk:
 {{{
 import uuid

 from django.contrib.auth.models import AbstractUser
 from django.db import models


 class UUIDUser(AbstractUser):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4)
 }}}
 And then tried:
 {{{
 python manage.py dumpdata uuiduser.UUIDUser
 [{"fields": {"username": "tim", "first_name": "", "last_name": "",
 "is_active": true,
 "is_superuser": true, "is_staff": true, "last_login":
 "2015-02-11T19:01:02.747Z",
 "groups": [], "user_permissions": [], "password": "...", "email":
 "a...@g.com",
 "date_joined": "2015-02-11T18:55:33.572Z"}, "model": "uuiduser.uuiduser",
 "pk": "dd100fcd-a894-4435-ad30-bdcd4671ac44"}]
 }}}
 Tested on SQLite and PostgreSQL. Could you provide more details? I'm also
 attached a test for Django's test suite that I tried writing to reproduce
 the issue.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.7495b7f7fb2db29e70f47de27914c544%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24326: Environment variables will work with mod_wsgi

2015-02-11 Thread Django

* status: new => closed
* needs_docs: => 0
* resolution: => needsinfo
* needs_tests: => 0
* needs_better_patch: => 0

Comment:

Hi Danny - I'm not clear what change in Django this ticket is requesting.
Nowhere in
[https://docs.djangoproject.com/en/1.7/howto/deployment/wsgi/modwsgi/ our
mod_wsgi docs] do we say that "you can't use environment variables with
mod_wsgi", or anything like that. In fact, we have a callout demonstrating
how to set an environment variable (`DJANGO_SETTINGS_MODULE`, the most
likely environment variable for people to want to set) in your `wsgi.py`
file, using the exact same technique shown in Graham's gist.

If there are any factual errors in that documentation, or something
missing that really should be added, maybe you (or someone) can clarify
what specific changes would be helpful? A pull request would be a great
way to do that :)

In the meantime, I'm closing this needsinfo as there's no clear path for
action.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.38f5b36a59d954136f7dfdd1809e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24326: Environment variables will work with mod_wsgi

2015-02-11 Thread Django

#24326: Environment variables will work with mod_wsgi
---+
 Reporter:  pydanny|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Nick Coghlan asked me to open this issue on djangoproject in a
 cookiecutter-django (a popular Django project template) issue in early
 December.

 According to Graham Dumpleton environment variables with Django on Apache
 will work. I have no suggestions to provide, no experience on the subject,
 no strong feelings on the subject, am merely providing reference points:

 * Graham's treatise:
 https://gist.github.com/GrahamDumpleton/b380652b768e81a7f60c
 * Related django-configurations issue: https://github.com/jezdez/django-
 configurations/issues/87
 * Another related django-configurations issue: https://github.com/jezdez
 /django-configurations/issues/53
 * Original issue opened on cookiecutter-django: https://github.com/pydanny
 /cookiecutter-django/issues/160

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.448ed576e0e14f0c764bf266c7148da5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24289: Is usage of many_to_one and one_to_many terms confusing for relation flags?

2015-02-11 Thread Django

#24289: Is usage of many_to_one and one_to_many terms confusing for relation 
flags?
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carljm):

 It looks like we have myself, Loic, and Aymeric in favor of swapping the
 current usage of `many_to_one` and `one_to_many` field flags. Anssi or
 Russell, do you have objections to moving ahead with that change?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.aef819be6c3ab4f206ee1fad8bb8ef18%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24215: Refactor of lazy model operations

2015-02-11 Thread Django

Comment (by AlexHill):

Actually, it's a bit more complicated than just having abstract models
fire class_prepared.

We try get_registered_model to see if a model is ready or not, which will
always fail with abstract models because they don't appear in the
registry. In the case that the abstract model really isn't ready, the
callback will still fire when it's constructed (assuming #21175 is fixed),
but only the first time.

Is there a reason the app registry doesn't keep track of abstract models?

Note these inconsistencies are present in Django now, they aren't
introduced by this patch. Again in practise it doesn't really matter – in
fact you get errors if some of the lazy operations *are* run with abstract
models. However if we want to be able to provide warnings for unhandled
lazy operations, we have to sort something out with abstract models or
they'll raise false alarms.

Cheers,
Alex

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.e99b8bf55ddafe60d96b8b9816a5b0fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

2015-02-11 Thread Django

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
    |  paulcollins
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  feature admin| Triage Stage:  Ready for
  readonly filefield |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by collinanderson):

 I also discovered that this takes precedence over list_display_links, but
 I think I like the new behavior.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/094.7f1434fe9be6d4d24f57b42357e3cfdf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

2015-02-11 Thread Django

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
    |  paulcollins
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  feature admin| Triage Stage:  Ready for
  readonly filefield |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Tim Graham ):

 In [changeset:"07cfe1bd822f4108b5029aef1615a17000d0b0dc"]:
 {{{
 #!CommitTicketReference repository=""
 revision="07cfe1bd822f4108b5029aef1615a17000d0b0dc"
 Refs #14497 -- Handled empty readonly admin FileFields
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/094.02d9e03d6f393da19a41b3a3147c297a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

2015-02-11 Thread Django

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
    |  paulcollins
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  feature admin| Triage Stage:  Ready for
  readonly filefield |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Tim Graham ):

 In [changeset:"343c0875338128dad162d4806fe908fb31404d14"]:
 {{{
 #!CommitTicketReference repository=""
 revision="343c0875338128dad162d4806fe908fb31404d14"
 [1.8.x] Refs #14497 -- Handled empty readonly admin FileFields

 Backport of 07cfe1bd822f4108b5029aef1615a17000d0b0dc from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/094.f85a0266f8e2de1446f41f5c15d2b218%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24290: postgres_tests fail ungracefully if psycopg2 isn't installed

2015-02-11 Thread Django

#24290: postgres_tests fail ungracefully if psycopg2 isn't installed
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  joelburton
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.8  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * keywords:   => 1.8
 * needs_better_patch:  0 => 1
 * easy:  1 => 0


Comment:

 There is a new problem on master (which affects 1.8 too, but it's a
 `RemovedInDjango19Warning` instead of a `RuntimeError`:
 {{{
 $ ./runtests.py postgres_tests
 ...
 Model class postgres_tests.models.IntegerArrayModel doesn't declare
 an explicit app_label and either isn't in an application in INSTALLED_APPS
 or else was imported before its application was loaded.
 }}}
 It's caused by the
 
[https://github.com/django/django/blob/8ec306a3a90aa2ec0baa4c9d8df68f0d49947a2c/tests/runtests.py#L87-L88
 hack in runtests.py] to omit the `postgres_tests` app when not running
 with a postgresql database (to avoid trying to apply the migrations when
 not in postgresql). I'm attaching a patch I experimented with, but there
 are still unsolved problems with it.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.12643e8379a807e3b8ea07d56396eec5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24215: Refactor of lazy model operations

2015-02-11 Thread Django

Comment (by AlexHill):

Hi Anssi,

Thanks for your feedback.

I have made some changes to the patch, notably:
* lazy_related_operation now takes multiple related model arguments.
* I've simplified and removed some now-unnecessary type checks in
[https://github.com/django/django/pull/3984/files#diff-
3010fc5a498b7171c342520f34507968R283 RelatedField.contribute_to_class] and
[https://github.com/django/django/pull/3984/files#diff-
3010fc5a498b7171c342520f34507968R2022
create_many_to_many_intermediary_model] (the latter now takes advantage of
the first bullet point)
* I've

[https://github.com/AlexHill/django/commit/d27869e3dcb03eccf7c3aa09d911b5206bda9d0a
made a change to how SQLite schema alterations work] due to a bit of
friction in the above. This is a small change in terms of code and I
believe for the better, but will want some eyes on it.

Regarding unhandled relations: if someone waits for a model that doesn't
exist the signal will never fire. I suppose at the end of the app
registry's loading phase would be a good place to check for those. Issuing
a warning might be the go, as it's always possible (though unlikely) that
the user intends to define a model later...

While looking into this, ran into #21175. Currently abstract models don't
fire class_prepared, so lazy operations involving abstract models remain
unhandled. In practise it doesn't matter because their concrete children
work fine, but it would be worth fixing.

Cheers,
Alex

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.be0d8b7202c800558b152e9625314d5a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24324: makemigrations fails with UnicodeDecodeError when path to project contains special characters

2015-02-11 Thread Django

#24324: makemigrations fails with UnicodeDecodeError when path to project 
contains
special characters
-+-
 Reporter:  notsqrt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.7
  commands)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.54b651d1a59016038c2d15b4aae11cbb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24321: `utils.http.same_origin` doesn't comply with RFC6454

2015-02-11 Thread Django

#24321: `utils.http.same_origin` doesn't comply with RFC6454
+-
 Reporter:  lukasklein  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by claudep):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.c63f0d424466ff9c6510c676ef6ab24d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format

2015-02-11 Thread Django

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  1.8alpha1
  (Serialization)|
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * component:  Utilities => Core (Serialization)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1f83ad85d2b4e3bea81e0d70db3a6313%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24299: `migrate auth` throws django.db.utils.IntegrityError

2015-02-11 Thread Django

#24299: `migrate auth` throws django.db.utils.IntegrityError
+-
 Reporter:  sir-sigurd  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8alpha1
 Severity:  Normal  |   Resolution:
 Keywords:  1.8-beta| Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by timgraham):

 * needs_tests:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.d9d74030b959fc5855d38831d9e76195%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24323: NameError: global name XXXXXAdmin is not defined when using admin register decorator with an init super call

2015-02-11 Thread Django

#24323: NameError: global name XAdmin is not defined when using admin 
register
decorator with an __init__ super call
---+
 Reporter:  eskhool|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Old description:

> When registering a django admin using the
> {{{
> @admin.register()
> class Admin(admin.ModelAdmin):
> def __init__(args, kwargs):
> super(Admin, self).__init__(args, kwargs)
> }}}
>
> gives an exception:
> {{{
> NameError: global name XAdmin is not defined
> }}}

New description:

 When registering a django admin using the
 {{{
 @admin.register()
 class Admin(admin.ModelAdmin):
 def __init__(self, *args, **kwargs):
 super(Admin, self).__init__(*args, **kwargs)
 }}}

 gives an exception:
 {{{
 NameError: global name XAdmin is not defined
 }}}

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.19486f4fbc7e6cb7943d95a5f6f90e9e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24325: Cannot reference FK relation from inline ModelForm.save()

2015-02-11 Thread Django

#24325: Cannot reference FK relation from inline ModelForm.save()
--+--
 Reporter:  Starou|Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  Forms |  Version:  1.8alpha1
 Severity:  Normal|   Resolution:
 Keywords:  inline ModelForm  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Starou):

 A small clarification: This exception happens when you add a new Author
 and create a Book with the inline in the same request.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.81a9b5c3a241becf0a27a7ac7cb74dc0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24324: makemigrations fails with UnicodeDecodeError when path to project contains special characters

2015-02-11 Thread Django

#24324: makemigrations fails with UnicodeDecodeError when path to project 
contains
special characters
-+-
 Reporter:  notsqrt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.7
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by notsqrt):

 #19357 supposedly fixed all the problems in django 1.5, but I also found
 that the template loader fails with non-ASCII path.

 Down the rabbit hole !

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ba27b4f53ed1233fa71f9910cc6d22d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23351: Admin Search Field error for related lookup

2015-02-11 Thread Django

#23351: Admin Search Field error for related lookup
-+-
 Reporter:  ebertti  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by zeraien):

 * status:  closed => new
 * severity:  Release blocker => Normal
 * cc: zeraien (added)
 * type:  Uncategorized => Bug
 * version:  1.7-rc-2 => 1.7
 * resolution:  worksforme =>


Comment:

 Replying to [comment:1 ramiro]:
 > I can't reproduce this with the information provided and using a simple
 setup containing only the code shown by the OP.
 >
 > Reopne if you can post more details.


 I discovered the problem seems to be related to this ticket:
 https://code.djangoproject.com/ticket/23697

 If using this:  `search_fields = ('module__name',)` but `name` does not
 exist in the `module` model, this error is thrown.

 Using django 1.7.3

 Full trace: https://gist.github.com/anonymous/f9abcb78c77466c35dcb

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c2607058890deb4944c1933ccc5a3252%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24325: Cannot reference FK relation from inline ModelForm.save()

2015-02-11 Thread Django

#24325: Cannot reference FK relation from inline ModelForm.save()
--+--
 Reporter:  Starou|Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  Forms |  Version:  1.8alpha1
 Severity:  Normal|   Resolution:
 Keywords:  inline ModelForm  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Starou):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Repo of a demo project: https://github.com/Starou/django-ticket24325

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.37cf8a19dc06717a0a144e1abef70661%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24325: Cannot reference FK relation from inline ModelForm.save()

2015-02-11 Thread Django

#24325: Cannot reference FK relation from inline ModelForm.save()
---+--
 Reporter:  Starou |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  1.8alpha1
 Severity:  Normal |   Keywords:  inline ModelForm
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 Hi devs,

 Not sure that's a bug but that's a regression. In Django-1.7 with the
 following models:

 {{{

 from django.db import models


 class Author(models.Model):
 name = models.TextField()


 class Book(models.Model):
 author = models.ForeignKey("Author")
 title = models.TextField()
 }}}

 You can access `book.author` in the `ModelForm.save()` method:
 admin.py:
 {{{
 from django import forms
 from django.contrib import admin
 from library import models


 class BookForm(forms.ModelForm):
 class Meta:
 model = models.Book
 exclude = ()

 def save(self, *args, **kwargs):
 book = super(BookForm, self).save(*args, **kwargs)
 book.title = "%s by %s" % (book.title, book.author.name)
 return book


 class BookInline(admin.TabularInline):
 model = models.Book
 extra = 1
 form = BookForm


 class AuthorAdmin(admin.ModelAdmin):
 inlines = [BookInline]


 admin.site.register(models.Author, AuthorAdmin)
 }}}

 And since commit
 
[https://github.com/django/django/commit/45e049937d2564d11035827ca9a9221b86215e45
 45e049937d] you get a `RelatedObjectDoesNotExist` exception: Book has no
 author.

 Is it considered a normal behaviour?

 Thanks.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.ae862204a186ef4479956229aa8c443e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24324: makemigrations fails with UnicodeDecodeError when path to project contains special characters

2015-02-11 Thread Django

#24324: makemigrations fails with UnicodeDecodeError when path to project 
contains
special characters
-+-
 Reporter:  notsqrt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.7
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by notsqrt):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 As a side-note, doing the following:

 {{{
 cd /tmp
 mkdir éhé
 cd éhé
 git clone https://github.com/django/django/
 cd tests
 pip install -r requirements/py2.txt  # this actually fails with pip < 6.0,
 due to the accents
 PYTHONPATH=..:$PYTHONPATH ./runtests.py
 }}}

 fails immediately ..

 So there's probably a massive work to fix all problems..

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f1b2d29f0b06d2d2dd661084afe145e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24324: makemigrations fails with UnicodeDecodeError when path to project contains special characters

2015-02-11 Thread Django

#24324: makemigrations fails with UnicodeDecodeError when path to project 
contains
special characters
+
 Reporter:  notsqrt |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.7
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Hi,

 Checked on linux, python 2.7, with Django 1.7.4.

 Steps to reproduce:

 {{{
 mktmpenv
 pip install Django
 cd /tmp/
 mkdir hého
 cd hého/
 django-admin startproject project
 cd project/
 python manage.py startapp app
 # add app to INSTALLED_APPS
 # add model to app.models
 python manage.py makemigrations app
 }}}

 Location:
 {{{
 django/db/migrations/writer.py", line 224, in path
 return os.path.join(basedir, self.filename)
 }}}

 Root of the bug: just a mix of bytes and text:
 {{{
 >>> import os
 >>> os.path.join(b'/tmp/hého', u'test')
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 6:
 ordinal not in range(128)
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.150a2b09e215b353271636d63645ecb7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

2015-02-11 Thread Django

#24319: UUIDField do not properly clean (validate) value in get_db_prep_value
-+-
 Reporter:  davidfischer-ch  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  clean,uuid   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * severity:  Normal => Release blocker
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.77df8bd268ace535bed7b1a6a86d200f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

2015-02-11 Thread Django

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  notsqrt
 Type:  New feature   |   Status:  closed
Component:  Core (System checks)  |  Version:  1.7
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by notsqrt):

 OK, it was incredibly hard to get it right anyway...

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.5a6eea48f77c58b7d4a2fc6b46f753d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11544: adjust admin css to not depend upon the !important declaration.

2015-02-11 Thread Django

#11544: adjust admin css to not depend upon the !important declaration.
--+
 Reporter:  kez.knight@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  css admin | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+
Changes (by collinanderson):

 * cc: cmawebsite@… (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.690eb9242cd8b6df0cb522bd91185e75%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22828: Model admins should return copies of its attributes

2015-02-11 Thread Django

#22828: Model admins should return copies of its attributes
---+--
 Reporter:  vzima  |Owner:  ericpauley
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 If you could write a patch, I'll be happy to review it.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.2bd24d2ef2ef48f4dbd810c6f6f06e82%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22828: Model admins should return copies of its attributes

2015-02-11 Thread Django

#22828: Model admins should return copies of its attributes
---+--
 Reporter:  vzima  |Owner:  ericpauley
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by synotna):

 This bug just hit me: I had set my base fields/readonly_fields on the
 ModelAdmin, and overwrote get_fields & get_readonly_fields thinking it
 would /always/ modify the base fields

 I highly recommend explaining in the docs for the getters that if you
 overwrite them, it should be to replace the setting of the fields directly
 on the ModelAdmin

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.b1471544b339bdb2fd9d331f7643e95d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24321: `utils.http.same_origin` doesn't comply with RFC6454

2015-02-11 Thread Django

#24321: `utils.http.same_origin` doesn't comply with RFC6454
+
 Reporter:  lukasklein  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by berkerpeksag):

 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.e8bc62c186a9210f324a9041da09e103%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22993: Drop skipIfCustomUser decorator

2015-02-11 Thread Django

#22993: Drop skipIfCustomUser decorator
--+
 Reporter:  timo  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 I'm not quite understanding your argument for why it would be advantageous
 to deprecate for 1.8. I think 1.9 is fine.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.aa1fde0fbc95796b764f9f8cf92f4861%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24112: Inconsistency in TestCase.assertInHTML

2015-02-11 Thread Django

#24112: Inconsistency in TestCase.assertInHTML
---+
 Reporter:  plumdog|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by plumdog):

 * needs_tests:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c0d6683817c0265765205095c358c833%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24323: NameError: global name XXXXXAdmin is not defined when using admin register decorator with an init super call

2015-02-11 Thread Django

#24323: NameError: global name XAdmin is not defined when using admin 
register
decorator with an __init__ super call
---+
 Reporter:  eskhool|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When registering a django admin using the
 {{{
 @admin.register()
 class Admin(admin.ModelAdmin):
 def __init__(args, kwargs):
 super(Admin, self).__init__(args, kwargs)
 }}}

 gives an exception:
 {{{
 NameError: global name XAdmin is not defined
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.ac56630cc2214f0ac42b18f89815c86f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24322: Increase consistency in the app registry

2015-02-11 Thread Django

#24322: Increase consistency in the app registry
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  app-loading  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * keywords:   => app-loading


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5352f5ded920422d4044fc25c3025d34%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24322: Increase consistency in the app registry

2015-02-11 Thread Django

#24322: Increase consistency in the app registry
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.26f079021510a9b1fa7b3773fbe7f6b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24322: Increase consistency in the app registry

2015-02-11 Thread Django

#24322: Increase consistency in the app registry
+
   Reporter:  aaugustin |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 As a follow-up to #21680, we should improve the implementation of the app
 registry to ensure that `set(self.all_models) in set(self.app_configs)`.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.1bc063ff0e0a3bf6d398841a60207ccd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24321: `utils.http.same_origin` doesn't comply with RFC6454

2015-02-11 Thread Django

#24321: `utils.http.same_origin` doesn't comply with RFC6454
+--
 Reporter:  lukasklein  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by lukasklein):

 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Old description:

> According to RFC6454 (http://tools.ietf.org/html/rfc6454#section-3.2.1)
> this should both be true:
>
> {{{#!python
> >>> from django.utils.http import same_origin
> >>> same_origin('http://google.com', 'http://google.com')
> True
> >>> same_origin('http://google.com', 'http://google.com:80')
> False
> }}}
>
> Quote:
>
> All of the following resources have the same origin:
>  http://example.com/
>  http://example.com:80/
>  http://example.com/path/file
> Each of the URIs has the same scheme, host, and port components.
>
> Django's `same_origin` uses the standard urllib, which will return an
> empty port if none is explicitly specified.
>
> My suggestion (see GitHub pull request) is to extend `same_origin` to use
> a protocol-to-port-mapping if no port is explicitly declared.

New description:

 According to RFC6454 (http://tools.ietf.org/html/rfc6454#section-3.2.1)
 this should both be true:

 {{{#!python
 >>> from django.utils.http import same_origin
 >>> same_origin('http://google.com', 'http://google.com')
 True
 >>> same_origin('http://google.com', 'http://google.com:80')
 False
 }}}

 Quote:

 All of the following resources have the same origin:
  http://example.com/
  http://example.com:80/
  http://example.com/path/file
 Each of the URIs has the same scheme, host, and port components.

 Django's `same_origin` uses the standard urllib, which will return an
 empty port if none is explicitly specified.

 My suggestion (see GitHub pull request:
 https://github.com/django/django/pull/4108) is to extend `same_origin` to
 use a protocol-to-port-mapping if no port is explicitly declared.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.0ff12b8395d611649988720fe4026ef0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24321: `utils.http.same_origin` doesn't comply with RFC6454

2015-02-11 Thread Django

#24321: `utils.http.same_origin` doesn't comply with RFC6454
+
 Reporter:  lukasklein  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Utilities   |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 According to RFC6454 (http://tools.ietf.org/html/rfc6454#section-3.2.1)
 this should both be true:

 {{{#!python
 >>> from django.utils.http import same_origin
 >>> same_origin('http://google.com', 'http://google.com')
 True
 >>> same_origin('http://google.com', 'http://google.com:80')
 False
 }}}

 Quote:

 All of the following resources have the same origin:
  http://example.com/
  http://example.com:80/
  http://example.com/path/file
 Each of the URIs has the same scheme, host, and port components.

 Django's `same_origin` uses the standard urllib, which will return an
 empty port if none is explicitly specified.

 My suggestion (see GitHub pull request) is to extend `same_origin` to use
 a protocol-to-port-mapping if no port is explicitly declared.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.e963d65923e4efef8e319fec8b63cc0a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format (was: Unable to serialize UUID field when running dumpdata with JSON format)

2015-02-11 Thread Django

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
+--
 Reporter:  jamesbeith  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  Version:  1.8alpha1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by jamesbeith):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0


Old description:

> A model with a UUID as its primary key. Running `dumpdata` management
> command with JSON output format (the default option) resulted in the
> following error
>
> {{{
> CommandError: Unable to serialize database: UUID('435697b4-954a-4b9a-
> a83a-2b53016b0d43') is not JSON serializable
> }}}
>
> However running again with `--format=xml` did not result in an error and
> `dumpdata` was successful.

New description:

 A model using a UUIDField as its primary key. Running `dumpdata`
 management command with JSON output format (the default option) resulted
 in the following error

 {{{
 CommandError: Unable to serialize database: UUID('435697b4-954a-4b9a-a83a-
 2b53016b0d43') is not JSON serializable
 }}}

 However running again with `--format=xml` did not result in an error and
 `dumpdata` was successful.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.759c56529705e780b0d098119d62ca6b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24320: Unable to serialize UUID field when running dumpdata with JSON format

2015-02-11 Thread Django

#24320: Unable to serialize UUID field when running dumpdata with JSON format
+---
 Reporter:  jamesbeith  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Utilities   |Version:  1.8alpha1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+---
 A model with a UUID as its primary key. Running `dumpdata` management
 command with JSON output format (the default option) resulted in the
 following error

 {{{
 CommandError: Unable to serialize database: UUID('435697b4-954a-4b9a-a83a-
 2b53016b0d43') is not JSON serializable
 }}}

 However running again with `--format=xml` did not result in an error and
 `dumpdata` was successful.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.466822b4e33ea414d4a8a9952f09622b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20846: Increase contrib.auth's User.username length

2015-02-11 Thread Django

#20846: Increase contrib.auth's User.username length
--+--
 Reporter:  ivoras@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by hwkns):

 Replying to [comment:14 freakboy3742]:
 > To me, the idea of a > 30 character *username* is pretty laughable -
 even *my* full name fits in 30 characters.
 Frankly, the length of your own name is irrelevant.  And being unable to
 imagine the need for a username longer than 30 characters is **not** a
 good reason to set that arbitrary limit.

 > If we *are* going to do this, a max_length of 254 makes the most sense
 to me (matching the length of the email field).
 Yes, 254 makes sense if we're talking about using email addresses as
 usernames, but that's still arbitrary.  Why limit the length of `username`
 in the model at all, when that can be easily accomplished in forms?  Why
 not use the largest maximum length for a `CharField` that is still
 supported by all the database backends?

 > I'm mostly bemused that people seem to have such an aversion to using
 CUSTOM_USER_MODEL ...
 Let me quote from the docs:
 > **Warning:**
 > Changing `AUTH_USER_MODEL` has a big effect on your database
 structure. It changes the tables that are available, and it will affect
 the construction of foreign keys and many-to-many relationships. If you
 intend to set `AUTH_USER_MODEL`, you should set it before creating any
 migrations or running `manage.py migrate` for the first time.
 > Changing this setting after you have tables created is not supported
 by `makemigrations` and will result in you having to manually fix your
 schema, port your data from the old user table, and possibly manually
 reapply some migrations.
 I can't imagine why anyone would be averse to that...

 > ... and that for some reason, using and/or contributing to a separate
 username model app third-party project is considered harder than pushing a
 patch into Django (a course of action that won't have practical results
 for 6-12 months).
 As it turns out, the mechanism used by the `longerusername` package to set
 the `max_length` of `User.username` is not available in Django 1.7, so
 yes, it is going to be considerably more difficult.  Even if it weren't,
 providing sensible defaults should be the goal of any good framework, so
 pushing a patch into Django is a worthwhile pursuit.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.07fa7def73e0c298be92202bd7a24c71%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

2015-02-11 Thread Django

#24319: UUIDField do not properly clean (validate) value in get_db_prep_value
--+
 Reporter:  davidfischer-ch   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8alpha1
 Severity:  Normal|   Keywords:  clean,uuid
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 '''Use case''': Using user's input to retrieve a model from database.

 '''Issue''': The UUIDField doesn't properly *clean* the input value,
 meaning the ORM will query the database even the query values aren't
 cleaned.

 '''System''': Ubuntu 14.04 LTS + PostgresSQL 9.3

 '''Good''': User.objects.get(pk='') -> ValueError
 '''Bad''': Media.objects.get(pk='') -> DataError

 {{{
 class Media(models.Model):
 pk = models.UUIDField()
 }}}

 {{{
 >>> User.objects.get(pk='')
 Traceback (most recent call last):
   File "", line 1, in 
   File "venv/src/django/django/db/models/manager.py", line 127, in
 manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "venv/src/django/django/db/models/query.py", line 320, in get
 clone = self.filter(*args, **kwargs)
   File "venv/src/django/django/db/models/query.py", line 671, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "venv/src/django/django/db/models/query.py", line 689, in
 _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "venv/src/django/django/db/models/sql/query.py", line 1284, in
 add_q
 clause, require_inner = self._add_q(where_part, self.used_aliases)
   File "venv/src/django/django/db/models/sql/query.py", line 1311, in
 _add_q
 current_negated=current_negated, connector=connector,
 allow_joins=allow_joins)
   File "venv/src/django/django/db/models/sql/query.py", line 1183, in
 build_filter
 condition = self.build_lookup(lookups, col, value)
   File "venv/src/django/django/db/models/sql/query.py", line 1079, in
 build_lookup
 return final_lookup(lhs, rhs)
   File "venv/src/django/django/db/models/lookups.py", line 96, in __init__
 self.rhs = self.get_prep_lookup()
   File "venv/src/django/django/db/models/lookups.py", line 134, in
 get_prep_lookup
 return self.lhs.output_field.get_prep_lookup(self.lookup_name,
 self.rhs)
   File "venv/src/django/django/db/models/fields/__init__.py", line 716, in
 get_prep_lookup
 return self.get_prep_value(value)
   File "venv/src/django/django/db/models/fields/__init__.py", line 974, in
 get_prep_value
 return int(value)
 ValueError: invalid literal for int() with base 10: ''

 }}}

 {{{
 >>> Media.objects.get(pk='')
 Traceback (most recent call last):
   File "", line 1, in 
   File "venv/src/django/django/db/models/manager.py", line 127, in
 manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "venv/src/django/django/db/models/query.py", line 326, in get
 num = len(clone)
   File "venv/src/django/django/db/models/query.py", line 145, in __len__
 self._fetch_all()
   File "venv/src/django/django/db/models/query.py", line 955, in
 _fetch_all
 self._result_cache = list(self.iterator())
   File "venv/src/django/django/db/models/query.py", line 239, in iterator
 results = compiler.execute_sql()
   File "venv/src/django/django/db/models/sql/compiler.py", line 826, in
 execute_sql
 cursor.execute(sql, params)
   File "venv/src/django/django/db/backends/utils.py", line 80, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "venv/src/django/django/db/backends/utils.py", line 65, in execute
 return self.cursor.execute(sql, params)
   File "venv/src/django/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "venv/src/django/django/utils/six.py", line 658, in reraise
 raise value.with_traceback(tb)
   File "venv/src/django/django/db/backends/utils.py", line 65, in execute
 return self.cursor.execute(sql, params)
 django.db.utils.DataError: invalid input syntax for uuid: ""
 LINE 1: ...oudncode_media" WHERE "cloudncode_media"."uuid" = '' LIM...
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit

53 matches

Mail list logo