date:20140930

Re: [Django] #23576: Fast-path deletion for MySQL (was: ORM delete strategy can lead to race conditions inside a transaction)

2014-09-30 Thread Django

* stage: Unreviewed => Accepted

Comment:

The best advice I can give is to start from
django/db/models/sql/subqueries.py and find update_can_self_select in
there. You might be able to use a different compiler for the original
query, one which does DELETE FROM instead of SELECT ...
FROM .

Note that even if you fix this, there are still cases where Django has to
fetch the IDs to memory, then delete only those IDs. The reason is that
Django needs to fire pre/post delete signals and cascade the deletion to
dependent models. Especially for pre-delete signal the model must still
exists in the database, so I don't see any other way than pre-fetch ids,
then delete those ids.

At least on PostgreSQL single query delete doesn't result in concurrency
safe behavior. For example, it is possible that the view deletes the
objects, another transaction commits an conflicting object, and then
finally the view commits its objects -> unique constraint violation.

I am marking this as accepted for allowing fast-path deletion for MySQL.

--
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.47fdd8655765d5cd7b851fccbbdbebfd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23576: ORM delete strategy can lead to race conditions inside a transaction

2014-09-30 Thread Django

#23576: ORM delete strategy can lead to race conditions inside a transaction
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jdufresne):

 This looks specific to database backends that do not support
 `update_can_self_select`. From the list of database backends shipped with
 Django, this applies only to MySQL.

 This is the race free query generated for backends supporting
 `update_can_self_select`.

 {{{
 DELETE FROM `myapp_c` WHERE `myapp_c`.`id` IN (SELECT U0.`id` AS `id` FROM
 `myapp_c` U0 INNER JOIN `myapp_a` U1 ON ( U0.`a_id` = U1.`id` ) INNER JOIN
 `myapp_b` U2 ON ( U0.`b_id` = U2.`id` ) WHERE (U1.`name` = 'foo' AND
 U2.`name` = 'bar'))
 }}}

 The problematic queries used by the MySQL:

 {{{
 SELECT `myapp_c`.`id` FROM `myapp_c` INNER JOIN `myapp_a` ON (
 `myapp_c`.`a_id` = `myapp_a`.`id` ) INNER JOIN `myapp_b` ON (
 `myapp_c`.`b_id` = `myapp_b`.`id` ) WHERE (`myapp_a`.`name` = 'foo' AND
 `myapp_b`.`name` = 'bar')
 DELETE FROM `myapp_c` WHERE `myapp_c`.`id` IN ({ RESULT FROM PREVIOUS
 QUERY })
 }}}

 The fact that this occurs across two queries allows rows to be inserted
 that would normally meet the criteria of the `WHERE` clause.

 One way to handle this would be to use MySQL's multiple table syntax
 http://dev.mysql.com/doc/refman/5.7/en/delete.html which allows joins. The
 query would be as simple as taking the `SELECT` query, removing the
 `SELECT` clause and replacing it with `DELETE myapp_c FROM myapp_c INNER
 JOIN ...`.

 I am interested in doing this, however, I'm not sure exactly where to
 start in order to build a better query. I see inside
 `DeleteQuery.delete_qs()` is where the check for feature
 `update_can_self_select` occurs. So perhaps a new feature check and branch
 should occur here. However, once the feature is checked, I'm not sure how
 to start building the alternative query. Any guidance would be
 appreciated.

--
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.3d7c803c3e6a9a457fbcfa62aa0133a5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23576: ORM delete strategy can lead to race conditions inside a transaction

2014-09-30 Thread Django

#23576: ORM delete strategy can lead to race conditions inside a transaction
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jdufresne):

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


Comment:

 I have created a minimal test case:
 https://github.com/jdufresne/djtest-23576 I'd be happy to answer any
 questions about the test case if anything requires explanation. The
 waiting on `stdin` is to simulate a view with a long running process
 inside a transaction.

 To run the test, run `$ python test.py` from the project root directory.
 (As it is a race condition it may take more than one try.)

 The test runs in a management command instead of a HTTP view in order to
 easily trigger the race using multiple processes, but the principle is the
 same. Imagine the command is the view and each process is an HTTP request.
 Upon running the test and triggering the error I get the following
 traceback:

 {{{
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 385, in
 execute_from_command_line
 utility.execute()
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 377, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 288, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 338, in execute
 output = self.handle(*args, **options)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 533, in handle
 return self.handle_noargs(**options)
   File "/home/jon/djtest/myproj/myapp/management/commands/mytest.py", line
 13, in handle_noargs
 C(a=A.objects.get(name='foo'), b=B.objects.get(name='bar'))
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/models/manager.py", line 92, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/models/query.py", line 409, in bulk_create
 self._batched_insert(objs_without_pk, fields, batch_size)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/models/query.py", line 938, in _batched_insert
 using=self.db)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/models/manager.py", line 92, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/models/query.py", line 921, in _insert
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 920, in execute_sql
 cursor.execute(sql, params)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 81, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 65, in execute
 return self.cursor.execute(sql, params)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/utils.py", line 94, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 65, in execute
 return self.cursor.execute(sql, params)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 128, in execute
 return self.cursor.execute(query, args)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/MySQLdb/cursors.py", line 205, in execute
 self.errorhandler(self, exc, value)
   File "/home/jon/djtest/venv/lib/python2.7/site-
 packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
 raise errorclass, errorvalue
 django.db.utils.IntegrityError: (1062, "Duplicate entry '1-1' for key
 'a_id'")
 }}}

--
Ticket URL:

Re: [Django] #23571: Empty order_by() doesn't work with slice

2014-09-30 Thread Django

#23571: Empty order_by() doesn't work with slice
-+-
 Reporter:  liminspace   |Owner:
 Type:  Bug  |  liminspace
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  order_by, slice  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by a1tus):

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


Comment:

 Are you sure? How have you checked that ordering is applied? I've checked
 it in my project and everything works as expected (no ordering in both
 cases).

--
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.fc4df152188d04c7acf864e715964c63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23577: CREATE INDEX-related OperationalError on migrating renamed models with colliding field names

2014-09-30 Thread Django

#23577: CREATE INDEX-related OperationalError on migrating renamed models with
colliding field names
+
 Reporter:  CrimsonZen  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 charettes):

 * stage:  Unreviewed => Accepted


Comment:

 Haven't reproduced but the issue seems legit from the report.

 I guess the `RenameModel` operation should also rename indexes generated
 from the original model 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/068.ca88f2c250aaf490f612c411d7e05fee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent

2014-09-30 Thread Django

#23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent
-+-
 Reporter:  alasdairnicol|Owner:
 Type:   |  alasdairnicol
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Alasdair Nicol ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"74c38bad1d80ff94a973f4c4608011f45e80f2d9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="74c38bad1d80ff94a973f4c4608011f45e80f2d9"
 [1.7.x] Fixed #23578 -- Changed examples in docs to use patterns
 }}}

--
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/071.3c880eaec71463d3a98a5d5043dfd1b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 74c38b: [1.7.x] Fixed #23578 -- Changed examples in docs t...

2014-09-30 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 74c38bad1d80ff94a973f4c4608011f45e80f2d9
  
https://github.com/django/django/commit/74c38bad1d80ff94a973f4c4608011f45e80f2d9
  Author: Alasdair Nicol 
  Date:   2014-10-01 (Wed, 01 Oct 2014)

  Changed paths:
M docs/topics/http/urls.txt

  Log Message:
  ---
  [1.7.x] Fixed #23578 -- Changed examples in docs to use patterns


-- 
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/542b52f64b5b5_69f43feed7efb2c088453%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent

2014-09-30 Thread Django

#23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent
-+-
 Reporter:  alasdairnicol|Owner:
 Type:   |  alasdairnicol
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by collinanderson):

 * component:  Uncategorized => Documentation
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => 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/071.a3b15233fac6a28f2b9caab698e51a36%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent

2014-09-30 Thread Django

#23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent
---+-
 Reporter:  alasdairnicol  |Owner:  alasdairnicol
 Type:  Uncategorized  |   Status:  assigned
Component:  Uncategorized  |  Version:  1.7
 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 alasdairnicol):

 * has_patch:  0 => 1


Comment:

 Pull request https://github.com/django/django/pull/3295/

--
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/071.a4c22ec153b1ee576cb31b5a1ecf9972%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent

2014-09-30 Thread Django

#23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent
---+-
 Reporter:  alasdairnicol  |Owner:  alasdairnicol
 Type:  Uncategorized  |   Status:  assigned
Component:  Uncategorized  |  Version:  1.7
 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 alasdairnicol):

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


Old description:

> Django 1.7.X supports using a list of `url()` instances for
> `urlpatterns`.
>
> In ticket #23277, it was decided to show the old `patterns` approach in
> the docs, and switch to the new style in the 1.8 docs.
>
> However, the [https://docs.djangoproject.com/en/1.7/topics/http/urls
> /#url-namespaces URL Namespaces] section of the URL Dispatcher docs uses
> the new style syntax. This could be a bit surprising for users
> unfamiliarwith the new syntax in 1.8.
>
> I'm going to open a small pull request which uses the old patterns syntax
> everywhere on the URL Dispatcher docs page in 1.7.X.

New description:

 Django 1.7.X supports using a list of `url()` instances for `urlpatterns`.

 In ticket #23277, it was decided to show the old `patterns` approach in
 the docs, and switch to the new style in the 1.8 docs.

 However, the [https://docs.djangoproject.com/en/1.7/topics/http/urls/#url-
 namespaces URL Namespaces] section of the URL Dispatcher docs uses the new
 style syntax. This could be a bit surprising for users unfamiliar with the
 new syntax in 1.8.

 I'm going to open a small pull request which uses the old patterns syntax
 everywhere on the URL Dispatcher docs page in 1.7.X.

--

--
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/071.55e8b84e3ff3b4830a62ecd56ae3485b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent

2014-09-30 Thread Django

#23578: Use patterns everwhere in 1.7.X URL dispatcher docs to be consistent
---+
 Reporter:  alasdairnicol  |  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
---+
 Django 1.7.X supports using a list of `url()` instances for `urlpatterns`.

 In ticket #23277, it was decided to show the old `patterns` approach in
 the docs, and switch to the new style in the 1.8 docs.

 However, the [https://docs.djangoproject.com/en/1.7/topics/http/urls/#url-
 namespaces URL Namespaces] section of the URL Dispatcher docs uses the new
 style syntax. This could be a bit surprising for users unfamiliarwith the
 new syntax in 1.8.

 I'm going to open a small pull request which uses the old patterns syntax
 everywhere on the URL Dispatcher docs page in 1.7.X.

--
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/056.6b3e8de8c997d4656a4a937546a5a58c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23534: Docs aren't clear if you can use certain template tags inside blocktrans

2014-09-30 Thread Django

#23534: Docs aren't clear if you can use certain template tags inside blocktrans
--+
 Reporter:  edu2004eu |Owner:  duane9
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by duane9):

 * owner:  nobody => duane9
 * 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.bdba3de10553a037fb98c419c0ba4a19%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23577: CREATE INDEX-related OperationalError on migrating renamed models with colliding field names

2014-09-30 Thread Django

#23577: CREATE INDEX-related OperationalError on migrating renamed models with
colliding field names
+--
 Reporter:  CrimsonZen  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 CrimsonZen):

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


Comment:

 It is worth noting that if you use postgres instead, the error is
 `django.db.utils.ProgrammingError: relation "sample_foo_4350f7d0" already
 exists`.

--
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.4acb0d9f519adf249bf2d1601baa3a9e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23577: CREATE INDEX-related OperationalError on migrating renamed models with colliding field names

2014-09-30 Thread Django

#23577: CREATE INDEX-related OperationalError on migrating renamed models with
colliding field names
+
 Reporter:  CrimsonZen  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 This one's a bit of an edge case, but I ran into it trying to refactor
 some models on my moderately large work project.

 Let's say I have a Django 1.7 app called `sample`:
 1. Create a model `Bar`.
 2. Create a model `Foo` with `bar = models.ForeignKey(Bar, blank=True,
 null=True)`
 3. `makemigrations` (migration `0001`)
 4. Rename `Foo` to `OldFoo`.
 5. `makemigrations`, say yes to the rename prompt (migration `0002`)
 6. Create new model `Foo`, which also has `bar = models.ForeignKey(Bar,
 blank=True, null=True)`
 7. `makemigrations` (migration `0003`)
 8. `migrate`

 When `migrate` hits `0003`, it throws this error:
 {{{django.db.utils.OperationalError: index sample_foo_4350f7d0 already
 exists}}}

 You may notice that `sqlmigrate sample 0001` and `sqlmigrate sample 0003`
 have the same line in both of them:
 {{{CREATE INDEX sample_foo_4350f7d0 ON "sample_foo" ("bar_id");}}}


 In my production case, I actually had no problems on servers, because
 South had created the index with a different name.  When I renamed the
 models and added a field, the new index did not collide with the old one.
 However, our test suite started failing, because it would run the
 migrations from the ground up, exposing the above bug.

 I haven't decided on a workaround yet, but I thought I'd bring this to
 your attention.  I might have to inject a migration that renames the index
 created in `0001`, or something to that effect.

 The attached test case has a project `dj17test` in the state after having
 performed all of the above steps.

--
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.7c7faaadd490661c6464c4245a89af32%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23569: settings.LOGGING_CONFIG assumes dictConfig()

2014-09-30 Thread Django

#23569: settings.LOGGING_CONFIG assumes dictConfig()
--+
 Reporter:  sethrh|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"fe2afcd318493c933ab1191a5a64271869a1227f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fe2afcd318493c933ab1191a5a64271869a1227f"
 Fixed #23569 -- Allowed using configs besides dictConfig in
 LOGGING_CONFIG.
 }}}

--
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.03962214900e47cb02ba66ea1164eeea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] fe2afc: Fixed #23569 -- Allowed using configs besides dict...

2014-09-30 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fe2afcd318493c933ab1191a5a64271869a1227f
  
https://github.com/django/django/commit/fe2afcd318493c933ab1191a5a64271869a1227f
  Author: Seth Hill 
  Date:   2014-09-30 (Tue, 30 Sep 2014)

  Changed paths:
M AUTHORS
M django/utils/log.py
M tests/logging_tests/tests.py

  Log Message:
  ---
  Fixed #23569 -- Allowed using configs besides dictConfig in LOGGING_CONFIG.


-- 
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/542b1e7961f1f_63dc3fb9f398b2b81021d7%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23574: Makemigrations tries to migrate non-model classes

2014-09-30 Thread Django

#23574: Makemigrations tries to migrate non-model classes
+--
 Reporter:  shredding   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:  invalid
 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 shredding):

 It turned out, that I just need to inherit the mixin from object to make
 it work in django 1.7

--
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.b2667637133259795d2044a43fcbfb7b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23574: Makemigrations tries to migrate non-model classes

2014-09-30 Thread Django

#23574: Makemigrations tries to migrate non-model classes
+--
 Reporter:  shredding   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:  invalid
 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 shredding):

 * status:  new => closed
 * resolution:   => invalid


--
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.4af642efd035116aa7073f3ce717b2a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19544: IntegrityError during Many To Many add()

2014-09-30 Thread Django

#19544: IntegrityError during Many To Many add()
-+-
 Reporter:  Kronuz   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jdufresne):

 * cc: jon.dufresne@… (added)


Comment:

 > I don't think comment:11 is talking about this ticket's issue (that is,
 it is not about m2m add()).

 I have moved my issue to ticket #23576.

--
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.f963ecd2930dab0590eade5e00d68672%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23576: ORM delete strategy can lead to race conditions inside a transaction

2014-09-30 Thread Django

#23576: ORM delete strategy can lead to race conditions inside a transaction
--+
 Reporter:  jdufresne |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Originally posted to #19544 due to similar error message, but I this is a
 different ticket.

 

 I have investigated this a bit more. For me the race occurs for the
 following reason:

 Suppose you have `MyModel` that has a unique constraint. Suppose you have
 a view of the form:

 {{{
 @transaction.atomic
 def my_view(request):
MyModel.objects.some_long_filter().delete()
objs = builds_list_of_unsaved_models_from_request(request)
MyModel.objects.bulk_create(objs)
 }}}

 That is, a view that builds a list of objects in bulk. The view first
 deletes the objects that were created by any previous requests to ensure
 the unique constraint is not violated. From my investigation, the
 `delete()` will not actually call an SQL `DELETE` statement directly -- as
 I would have expected -- but instead caches a list of ids of objects that
 exist, then calls a new SQL query with a `DELETE .. WHERE id IN (list of
 ids)`. This all happens in `DeleteQuery.delete_qs()` file
 `django/db/models/sql/subqueries.py:52`.

 Now suppose you have some original data. Then, two requests occur at the
 same time. The first request and the second request will both cache the
 same ids from the original data to delete. Suppose the first request
 finishes slightly earlier and commits the *new objects with new ids*. Now,
 the second request will try to delete the cached ids from the original
 data and *not* the newly created ids the first request. Upon save there is
 a unique constraint violation -- as the wrong ids were deleted -- causing
 an `IntegrityError`.

 Coming from an application with many raw SQL queries, this unique
 constraint violation was a big surprise inside a transaction. The caching
 of ids in the `delete()` function seems a sneaky source of race
 conditions.

 

 Traceback when the IntegrityError occurs:

 {{{
 Traceback (most recent call last):
   File "manage.py", line 13, in 
 execute_from_command_line(sys.argv)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 399, in
 execute_from_command_line
 utility.execute()
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 392, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 242, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 285, in execute
 output = self.handle(*args, **options)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 415, in handle
 return self.handle_noargs(**options)
   File
 "/home/jon/devel/myproj/development/myapp/management/commands/thetest.py",
 line 36, in handle_noargs
 MyModel.objects.bulk_create(objs)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/db/models/manager.py", line 160, in bulk_create
 return self.get_queryset().bulk_create(*args, **kwargs)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/db/models/query.py", line 359, in bulk_create
 self._batched_insert(objs_without_pk, fields, batch_size)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/db/models/query.py", line 838, in _batched_insert
 using=self.db)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/db/models/manager.py", line 232, in _insert
 return insert_query(self.model, objs, fields, **kwargs)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/db/models/query.py", line 1514, in insert_query
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 903, in execute_sql
 cursor.execute(sql, params)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-
 packages/django/db/backends/util.py", line 69, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/jon/devel/myproj/development/venv/lib/python2.7/site-

Re: [Django] #23569: settings.LOGGING_CONFIG assumes dictConfig()

2014-09-30 Thread Django

#23569: settings.LOGGING_CONFIG assumes dictConfig()
--+
 Reporter:  sethrh|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  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 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/064.cf8beedc4dc5b905e81bf7107cdb5537%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] d6a150: Updated translations from Transifex

2014-09-30 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d6a15026c4234c732bd2db0b39e1b1e478b1286e
  
https://github.com/django/django/commit/d6a15026c4234c732bd2db0b39e1b1e478b1286e
  Author: Claude Paroz 
  Date:   2014-09-30 (Tue, 30 Sep 2014)

  Changed paths:
M django/conf/locale/af/LC_MESSAGES/django.mo
M django/conf/locale/af/LC_MESSAGES/django.po
M django/conf/locale/ar/LC_MESSAGES/django.mo
M django/conf/locale/ar/LC_MESSAGES/django.po
M django/conf/locale/ast/LC_MESSAGES/django.mo
M django/conf/locale/ast/LC_MESSAGES/django.po
M django/conf/locale/az/LC_MESSAGES/django.mo
M django/conf/locale/az/LC_MESSAGES/django.po
M django/conf/locale/be/LC_MESSAGES/django.mo
M django/conf/locale/be/LC_MESSAGES/django.po
M django/conf/locale/bg/LC_MESSAGES/django.mo
M django/conf/locale/bg/LC_MESSAGES/django.po
M django/conf/locale/bn/LC_MESSAGES/django.mo
M django/conf/locale/bn/LC_MESSAGES/django.po
M django/conf/locale/br/LC_MESSAGES/django.mo
M django/conf/locale/br/LC_MESSAGES/django.po
M django/conf/locale/bs/LC_MESSAGES/django.mo
M django/conf/locale/bs/LC_MESSAGES/django.po
M django/conf/locale/ca/LC_MESSAGES/django.mo
M django/conf/locale/ca/LC_MESSAGES/django.po
M django/conf/locale/cs/LC_MESSAGES/django.mo
M django/conf/locale/cs/LC_MESSAGES/django.po
M django/conf/locale/cy/LC_MESSAGES/django.mo
M django/conf/locale/cy/LC_MESSAGES/django.po
M django/conf/locale/da/LC_MESSAGES/django.mo
M django/conf/locale/da/LC_MESSAGES/django.po
M django/conf/locale/de/LC_MESSAGES/django.mo
M django/conf/locale/de/LC_MESSAGES/django.po
M django/conf/locale/el/LC_MESSAGES/django.mo
M django/conf/locale/el/LC_MESSAGES/django.po
M django/conf/locale/en_AU/LC_MESSAGES/django.mo
M django/conf/locale/en_AU/LC_MESSAGES/django.po
M django/conf/locale/en_GB/LC_MESSAGES/django.mo
M django/conf/locale/en_GB/LC_MESSAGES/django.po
M django/conf/locale/eo/LC_MESSAGES/django.mo
M django/conf/locale/eo/LC_MESSAGES/django.po
M django/conf/locale/es/LC_MESSAGES/django.mo
M django/conf/locale/es/LC_MESSAGES/django.po
M django/conf/locale/es_AR/LC_MESSAGES/django.mo
M django/conf/locale/es_AR/LC_MESSAGES/django.po
M django/conf/locale/es_MX/LC_MESSAGES/django.mo
M django/conf/locale/es_MX/LC_MESSAGES/django.po
M django/conf/locale/es_VE/LC_MESSAGES/django.mo
M django/conf/locale/es_VE/LC_MESSAGES/django.po
M django/conf/locale/et/LC_MESSAGES/django.mo
M django/conf/locale/et/LC_MESSAGES/django.po
M django/conf/locale/eu/LC_MESSAGES/django.mo
M django/conf/locale/eu/LC_MESSAGES/django.po
M django/conf/locale/fa/LC_MESSAGES/django.mo
M django/conf/locale/fa/LC_MESSAGES/django.po
M django/conf/locale/fi/LC_MESSAGES/django.mo
M django/conf/locale/fi/LC_MESSAGES/django.po
M django/conf/locale/fr/LC_MESSAGES/django.mo
M django/conf/locale/fr/LC_MESSAGES/django.po
M django/conf/locale/fy/LC_MESSAGES/django.mo
M django/conf/locale/fy/LC_MESSAGES/django.po
M django/conf/locale/ga/LC_MESSAGES/django.mo
M django/conf/locale/ga/LC_MESSAGES/django.po
M django/conf/locale/gl/LC_MESSAGES/django.mo
M django/conf/locale/gl/LC_MESSAGES/django.po
M django/conf/locale/he/LC_MESSAGES/django.mo
M django/conf/locale/he/LC_MESSAGES/django.po
M django/conf/locale/hi/LC_MESSAGES/django.mo
M django/conf/locale/hi/LC_MESSAGES/django.po
M django/conf/locale/hr/LC_MESSAGES/django.mo
M django/conf/locale/hr/LC_MESSAGES/django.po
M django/conf/locale/hu/LC_MESSAGES/django.mo
M django/conf/locale/hu/LC_MESSAGES/django.po
M django/conf/locale/ia/LC_MESSAGES/django.mo
M django/conf/locale/ia/LC_MESSAGES/django.po
M django/conf/locale/id/LC_MESSAGES/django.mo
M django/conf/locale/id/LC_MESSAGES/django.po
M django/conf/locale/io/LC_MESSAGES/django.mo
M django/conf/locale/io/LC_MESSAGES/django.po
M django/conf/locale/is/LC_MESSAGES/django.mo
M django/conf/locale/is/LC_MESSAGES/django.po
M django/conf/locale/it/LC_MESSAGES/django.mo
M django/conf/locale/it/LC_MESSAGES/django.po
M django/conf/locale/ja/LC_MESSAGES/django.mo
M django/conf/locale/ja/LC_MESSAGES/django.po
M django/conf/locale/ka/LC_MESSAGES/django.mo
M django/conf/locale/ka/LC_MESSAGES/django.po
M django/conf/locale/kk/LC_MESSAGES/django.mo
M django/conf/locale/kk/LC_MESSAGES/django.po
M django/conf/locale/km/LC_MESSAGES/django.mo
M django/conf/locale/km/LC_MESSAGES/django.po
M django/conf/locale/kn/LC_MESSAGES/django.mo
M django/conf/locale/kn/LC_MESSAGES/django.po
M django/conf/locale/ko/LC_MESSAGES/django.mo
M django/conf/locale/ko/LC_MESSAGES/django.po
M django/conf/locale/lb/LC_MESSAGES/django.mo
M django/conf/locale/lb/LC_MESSAGES/django.po
M django/conf/locale/lt/LC_MESSAGES/django.mo

[django/django] e9c8ae: [1.7.x] Updated translations from Transifex

2014-09-30 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: e9c8aefbcee51d4c2fdda716450061ad7beaa01b
  
https://github.com/django/django/commit/e9c8aefbcee51d4c2fdda716450061ad7beaa01b
  Author: Claude Paroz 
  Date:   2014-09-30 (Tue, 30 Sep 2014)

  Changed paths:
M django/conf/locale/af/LC_MESSAGES/django.mo
M django/conf/locale/af/LC_MESSAGES/django.po
M django/conf/locale/ar/LC_MESSAGES/django.mo
M django/conf/locale/ar/LC_MESSAGES/django.po
M django/conf/locale/ast/LC_MESSAGES/django.mo
M django/conf/locale/ast/LC_MESSAGES/django.po
M django/conf/locale/az/LC_MESSAGES/django.mo
M django/conf/locale/az/LC_MESSAGES/django.po
M django/conf/locale/be/LC_MESSAGES/django.mo
M django/conf/locale/be/LC_MESSAGES/django.po
M django/conf/locale/bg/LC_MESSAGES/django.mo
M django/conf/locale/bg/LC_MESSAGES/django.po
M django/conf/locale/bn/LC_MESSAGES/django.mo
M django/conf/locale/bn/LC_MESSAGES/django.po
M django/conf/locale/br/LC_MESSAGES/django.mo
M django/conf/locale/br/LC_MESSAGES/django.po
M django/conf/locale/bs/LC_MESSAGES/django.mo
M django/conf/locale/bs/LC_MESSAGES/django.po
M django/conf/locale/ca/LC_MESSAGES/django.mo
M django/conf/locale/ca/LC_MESSAGES/django.po
M django/conf/locale/cs/LC_MESSAGES/django.mo
M django/conf/locale/cs/LC_MESSAGES/django.po
M django/conf/locale/cy/LC_MESSAGES/django.mo
M django/conf/locale/cy/LC_MESSAGES/django.po
M django/conf/locale/da/LC_MESSAGES/django.mo
M django/conf/locale/da/LC_MESSAGES/django.po
M django/conf/locale/de/LC_MESSAGES/django.mo
M django/conf/locale/de/LC_MESSAGES/django.po
M django/conf/locale/el/LC_MESSAGES/django.mo
M django/conf/locale/el/LC_MESSAGES/django.po
M django/conf/locale/en_AU/LC_MESSAGES/django.mo
M django/conf/locale/en_AU/LC_MESSAGES/django.po
M django/conf/locale/en_GB/LC_MESSAGES/django.mo
M django/conf/locale/en_GB/LC_MESSAGES/django.po
M django/conf/locale/eo/LC_MESSAGES/django.mo
M django/conf/locale/eo/LC_MESSAGES/django.po
M django/conf/locale/es/LC_MESSAGES/django.mo
M django/conf/locale/es/LC_MESSAGES/django.po
M django/conf/locale/es_AR/LC_MESSAGES/django.mo
M django/conf/locale/es_AR/LC_MESSAGES/django.po
M django/conf/locale/es_MX/LC_MESSAGES/django.mo
M django/conf/locale/es_MX/LC_MESSAGES/django.po
M django/conf/locale/es_VE/LC_MESSAGES/django.mo
M django/conf/locale/es_VE/LC_MESSAGES/django.po
M django/conf/locale/et/LC_MESSAGES/django.mo
M django/conf/locale/et/LC_MESSAGES/django.po
M django/conf/locale/eu/LC_MESSAGES/django.mo
M django/conf/locale/eu/LC_MESSAGES/django.po
M django/conf/locale/fa/LC_MESSAGES/django.mo
M django/conf/locale/fa/LC_MESSAGES/django.po
M django/conf/locale/fi/LC_MESSAGES/django.mo
M django/conf/locale/fi/LC_MESSAGES/django.po
M django/conf/locale/fr/LC_MESSAGES/django.mo
M django/conf/locale/fr/LC_MESSAGES/django.po
M django/conf/locale/fy/LC_MESSAGES/django.mo
M django/conf/locale/fy/LC_MESSAGES/django.po
M django/conf/locale/ga/LC_MESSAGES/django.mo
M django/conf/locale/ga/LC_MESSAGES/django.po
M django/conf/locale/gl/LC_MESSAGES/django.mo
M django/conf/locale/gl/LC_MESSAGES/django.po
M django/conf/locale/he/LC_MESSAGES/django.mo
M django/conf/locale/he/LC_MESSAGES/django.po
M django/conf/locale/hi/LC_MESSAGES/django.mo
M django/conf/locale/hi/LC_MESSAGES/django.po
M django/conf/locale/hr/LC_MESSAGES/django.mo
M django/conf/locale/hr/LC_MESSAGES/django.po
M django/conf/locale/hu/LC_MESSAGES/django.mo
M django/conf/locale/hu/LC_MESSAGES/django.po
M django/conf/locale/ia/LC_MESSAGES/django.mo
M django/conf/locale/ia/LC_MESSAGES/django.po
M django/conf/locale/id/LC_MESSAGES/django.mo
M django/conf/locale/id/LC_MESSAGES/django.po
M django/conf/locale/io/LC_MESSAGES/django.mo
M django/conf/locale/io/LC_MESSAGES/django.po
M django/conf/locale/is/LC_MESSAGES/django.mo
M django/conf/locale/is/LC_MESSAGES/django.po
M django/conf/locale/it/LC_MESSAGES/django.mo
M django/conf/locale/it/LC_MESSAGES/django.po
M django/conf/locale/ja/LC_MESSAGES/django.mo
M django/conf/locale/ja/LC_MESSAGES/django.po
M django/conf/locale/ka/LC_MESSAGES/django.mo
M django/conf/locale/ka/LC_MESSAGES/django.po
M django/conf/locale/kk/LC_MESSAGES/django.mo
M django/conf/locale/kk/LC_MESSAGES/django.po
M django/conf/locale/km/LC_MESSAGES/django.mo
M django/conf/locale/km/LC_MESSAGES/django.po
M django/conf/locale/kn/LC_MESSAGES/django.mo
M django/conf/locale/kn/LC_MESSAGES/django.po
M django/conf/locale/ko/LC_MESSAGES/django.mo
M django/conf/locale/ko/LC_MESSAGES/django.po
M django/conf/locale/lb/LC_MESSAGES/django.mo
M django/conf/locale/lb/LC_MESSAGES/django.po
M

Re: [Django] #23575: Add a code example for custom AdminSite

2014-09-30 Thread Django

#23575: Add a code example for custom AdminSite
--+
 Reporter:  hernandocounty|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  TEMPLATES_DIR | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by hernandocounty):

 Yes but even that method is too much. Like I said, The guy on stack
 overflow had the simplest solution of just editing urls.py

 and yes I did have the templates directory in the right place.

 I am seriously confused as to why it did not work. Everything you suggest
 I have tried.

 I think the only solution is for me to start it over in a new VM and
 document my process. Until then we wont have the same data to work with .

--
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/072.c5068cd4cd878828a71597159dc5630f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15089: contrib.sites and multitenancy

2014-09-30 Thread Django

#15089: contrib.sites and multitenancy
---+
 Reporter:  legutierr  |Owner:  apollo13
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:
 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
---+

Comment (by timgraham):

 Made some updates to the patch:
 [https://github.com/django/django/pull/3293 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/067.4e5bec964ab9c8543cc25eee34e0b5a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Add a code example for custom AdminSite (was: Templates override with Admin Site TEMPLATE_DIRS better method possibly)

2014-09-30 Thread Django

* component: Template system => Documentation
* type: New feature => Cleanup/optimization
* easy: 0 => 1
* stage: Unreviewed => Accepted

Comment:

I probably wouldn't include the alternative in the tutorial itself since
`site_header` is already linked to the admin docs. The instructions are on
that page:
"If you’d like to set up your own administrative site with custom
behavior, however, you’re free to subclass AdminSite and override or add
anything you like. Then, simply create an instance of your AdminSite
subclass (the same way you’d instantiate any other Python class), and
register your models and ModelAdmin subclasses with it instead of using
the default."

but a code example would be helpful.

I'd guess maybe you didn't setup the directory structure quite right in
order for template overriding to work. It should be
`mysite/templates/admin` and not `mysite/mysite/templates/admin`.

--
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/072.88ae5b9ae7aefe4f412609a4171a8852%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

#23575: Templates override with Admin Site TEMPLATE_DIRS better method
possibly
-+--
Reporter: hernandocounty |Owner: nobody
Type: New feature | Status: new
Component: Template system | Version: 1.7
Severity: Normal | Resolution:
Keywords: TEMPLATES_DIR| Triage Stage: Unreviewed
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+--

Comment (by hernandocounty):

Awesome. Wow man thanks for listening. Really Cool . Ok . Could we just
make another section and just call it Alternative method to do this ?
something simple. I really do feel like it fits the DRY principle . As for
what is in the Tutorial. Is there something I missed that makes it
difficult to execute ? I seriously spent quite a bit of time on it and
would even be willing to start it over from scratch and screenshot it all
. Maybe I would find a common mistake / pitfall that occurs for newbs like
me ?

--
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/072.b712b790b03448a15ee2b1f47e6cb25a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] c7b588: Fixed flake8 warnings.

2014-09-30 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c7b5883c781608f20f42ebedbfc260ea082709d6
  
https://github.com/django/django/commit/c7b5883c781608f20f42ebedbfc260ea082709d6
  Author: Tim Graham 
  Date:   2014-09-30 (Tue, 30 Sep 2014)

  Changed paths:
M tests/test_utils/models.py

  Log Message:
  ---
  Fixed flake8 warnings.


-- 
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/542ae7b470f91_703f3f83d67672a05818f%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23573: Should tutorial 2 demonstrate AdminSite.site_header instead of overriding templates?

2014-09-30 Thread Django

#23573: Should tutorial 2 demonstrate AdminSite.site_header instead of 
overriding
templates?
-+-
 Reporter:  hernandocounty   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.7
Component:  Documentation|   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Mmm, in fact the discussion reached the same point in #23575 (unless I
 missed something).

--
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/072.c7e99d0307716731ebc28d52d482d1b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23573: Should tutorial 2 demonstrate AdminSite.site_header instead of overriding templates? (was: Templates override with Admin Site TEMPLATE_DIRS wrong way)

2014-09-30 Thread Django

#23573: Should tutorial 2 demonstrate AdminSite.site_header instead of 
overriding
templates?
--+
 Reporter:  hernandocounty|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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 aaugustin):

 * status:  closed => new
 * component:  Template system => Documentation
 * keywords:  TEMPLATES_DIR =>
 * needs_docs:  1 => 0
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Old description:

> ok just because I got my ass reemed by a bunch of overly sensitive people
> in my opinion,
>
> here is a better version of my point.
>
> we have a DRY principle with Django.
>
> it saves us time
>
> so the 1.7 thingy cost me some time.   not that big of a deal. but
> evidently complaining to volunteers is.
>
> So whatever.. take it how you will. I would certainly be happy to
> contribute to documentation but mostly my experience with these
> opensource projects is most of the people that run them think they are
> GODS of computer world and are usually rude in the first place and would
> not give me the time of day to contribute anyways.
>
> I love Django. I love Open Source. I love all the people that contribute
> to this stuff. Honestly Do.
>
> So here is the way I found to do this a little easier.
>
> http://stackoverflow.com/questions/4938491/django-admin-change-header-
> django-administration-text

New description:

 Tutorial 2 shows how to change the admin's header (see also #21378).

 However, in Django 1.7, there's a better way to achieve this particular
 task:
 
[https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#django.contrib.admin.AdminSite.site_header
 AdminSite.site_header].

 If that example is intended to demonstrate how to override a template,
 then it should tackle another use case for which overriding templates is
 the simplest choice.

 If it is intended to show how to customize the admin's header, then it
 should describe the simplest solution.

--

Comment:

 I've rewritten the ticket because the state of the reporter's ass is only
 marginally relevant to the Django project ;-) However, the idea is valid.

--
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/072.8648c8ca902e34b23e16b0d90ceb9bd9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

#23575: Templates override with Admin Site   TEMPLATE_DIRS  better method 
possibly
-+--
 Reporter:  hernandocounty   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  TEMPLATES_DIR| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by timgraham):

 Oh now I understand your suggestion. Well, we don't use that method for
 the reason described in the tutorial, "We use this approach to teach you
 how to override templates. In an actual project, you would probably use
 the django.contrib.admin.AdminSite.site_header attribute to more easily
 make this particular customization." So I am not sure what we should do.
 Suggestions?

--
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/072.8f44545be310b06358a0a6217b5bd2bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

#23575: Templates override with Admin Site   TEMPLATE_DIRS  better method 
possibly
-+--
 Reporter:  hernandocounty   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  TEMPLATES_DIR| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by hernandocounty):

 yes I am using the 1.7 tutorial.

 I tried the other methods when the 1.7 version did not work.

 There was no error message.. It was just that the Site Admin Text did not
 change unless I edited urls.py, which took all of 3 seconds as opposed to
 the 24 hours of trying the method on the tutorial.

 Im not trying to be a dick man.. just trying to help and I know other
 people have had this problem.

--
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/072.49368eee049f097c7b3df092a1ce7135%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

#23575: Templates override with Admin Site   TEMPLATE_DIRS  better method 
possibly
-+--
 Reporter:  hernandocounty   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  TEMPLATES_DIR| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by hernandocounty):

 I followed the tutorial as best as a guy with a physics degree can. If it
 confuses me, It probably confuses a lot of other people too.

--
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/072.ce060446e168d8853b4d38000dc9f969%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

#23575: Templates override with Admin Site   TEMPLATE_DIRS  better method 
possibly
-+--
 Reporter:  hernandocounty   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  TEMPLATES_DIR| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by timgraham):

 Are you using the version of the tutorial that matches the version of
 Django you have installed? It's not clear to me what the problem is
 besides things "not working." Did you find your error? Without knowing
 that, I'm not sure how things should be clarified. See
 [https://docs.djangoproject.com/en/dev/#getting-help Getting Help] if you
 need to help resolving the problem, as we try to avoid using this ticket
 tracker as a support channel.

--
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/072.7582bb2526259eed541931facd07ad93%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

Comment (by hernandocounty):

Im not looking for support. I have the problem fixed by the method on
the link I sent you by editing the urls.py instead of the settings.py and
the TEMPLATE_DIRS method.

You guys are way ahead of guys like me. You guys understand this stuff in
a different way . You wrote it Probably. But myself, I have a background
in Physics and am about Jr Level Django guy.

I am honeslty trying to help the documentation, Not looking for Support.

Editing the urls.py solution is much faster and makes more sense to guys
at my level IMHO.

the guy on the stack overflow even said in 1.7 things are different with
TEMPLATES_DIRS and its only necessary to edit urls.py to achieve the
result of changing the title of the admin site.

--
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/072.fa0a31ab9736fcfc2b06457fdf71d582%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

Comment (by hernandocounty):

Customizing your project’s templates

Create a templates directory in your project directory. Templates can live
anywhere on your filesystem that Django can access. (Django runs as
whatever user your server runs.) However, keeping your templates within
the project is a good convention to follow.

Open your settings file (mysite/settings.py, remember) and add a
TEMPLATE_DIRS setting:
mysite/settings.py

TEMPLATE_DIRS = [os.path.join(BASE_DIR, 'templates')]

TEMPLATE_DIRS is an iterable of filesystem directories to check when
loading Django templates; it’s a search path.

Now create a directory called admin inside templates, and copy the
template admin/base_site.html from within the default Django admin
template directory in the source code of Django itself
(django/contrib/admin/templates) into that directory.

this is what I tried along with these solutions also.

i tried these solutions from earlier versions

# TEMPLATE_DIRS = [os.path.join(BASE_DIR,
'/home//dev/09292014/stocks_day1/templates/')]

TEMPLATE_DIRS = ('/home//dev/09292014/stocks_day1/templates',)

these i placed in settings.py after trying the method in the tutorial.

Thanks

Doug

--
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/072.503c92d3d759430dbfbbd326a2d8e651%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23502: Request for an escape_all filter for non alphanumeric chars with ASCII values less than 256

2014-09-30 Thread Django

#23502: Request for an escape_all filter for non alphanumeric chars with ASCII
values less than 256
-+--
 Reporter:  djbug|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Utilities|  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 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 timgraham):

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


Comment:

 I think it would be better to start this off as a 3rd party package to
 prove there is sufficient interest for its inclusion in core.

--
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.cbab0382f4560c0b86b8d35b3d283fcd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23465: Inheritance destroying data in original model

2014-09-30 Thread Django

#23465: Inheritance destroying data in original model
-+-
 Reporter:  leandropls   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => duplicate


--
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.96b3bad02eb92d9729a324ede00b8d72%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

#23575: Templates override with Admin Site   TEMPLATE_DIRS  better method 
possibly
-+--
 Reporter:  hernandocounty   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  TEMPLATES_DIR| Triage Stage:  Unreviewed
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_tests:   => 0
 * needs_docs:   => 0


Comment:

 You can read about
 [https://docs.djangoproject.com/en/1.7/internals/contributing/writing-
 documentation/ contributing to our documentation]. From your report, it's
 not clear where the error is in our docs.

--
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/072.b2c0350a6f138464173784169d43a436%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23575: Templates override with Admin Site TEMPLATE_DIRS better method possibly

2014-09-30 Thread Django

#23575: Templates override with Admin Site   TEMPLATE_DIRS  better method 
possibly
-+---
 Reporter:  hernandocounty   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Template system  |Version:  1.7
 Severity:  Normal   |   Keywords:  TEMPLATES_DIR
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+---
 the current way listed did not work for me.

 It would behoove the beautiful documentation of Django to make it a little
 more clear.

 http://stackoverflow.com/questions/4938491/django-admin-change-header-
 django-administration-text

 here is the link.

 I would be delighted to help in this project.

 thanks

 Doug


 Is there anything else I could do to help ?

 If you tell me what info you need and don't treat me like I'm an idiot I
 would love to help.

 Sorry Just had a lot of negative experiences trying to contribute to
 projects.

--
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/057.d29814da7927a3a01fc240af6a5098d5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23573: Templates override with Admin Site TEMPLATE_DIRS wrong way

2014-09-30 Thread Django

#23573: Templates override with Admin Site   TEMPLATE_DIRS  wrong way
-+-
 Reporter:  hernandocounty   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.7
Component:  Template system  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  TEMPLATES_DIR|  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by hernandocounty:

Old description:

> this is the way I finally got this done. After almost 2 days guys.
> Django Project this is unacceptable. We pride ourselves in DRY and
> documentation but on version 1.7 Tutorial you tell the absolute WRONG WAY
> to change the look of the ADMIN SITE.
>
> http://stackoverflow.com/questions/4938491/django-admin-change-header-
> django-administration-text
>
> this is the only way I got it to work ...
>
> by editing urls.py   not by loading TEMPLATE blah blah and os.path.join
> crap  and all this two days of my life wasted on SHIT Documenation guys
>   the 1.7 examples are no good .  Part two of Tutorial of change the
> look of admin site with TEMPLATE_DIRS  that stuff doesnt work.
>
> I love this project.   But you guys know as well as I do, this is not OK.
>
> Thanks
>
> Doug

New description:

 ok just because I got my ass reemed by a bunch of overly sensitive people
 in my opinion,

 here is a better version of my point.

 we have a DRY principle with Django.

 it saves us time

 so the 1.7 thingy cost me some time.   not that big of a deal. but
 evidently complaining to volunteers is.

 So whatever.. take it how you will. I would certainly be happy to
 contribute to documentation but mostly my experience with these opensource
 projects is most of the people that run them think they are GODS of
 computer world and are usually rude in the first place and would not give
 me the time of day to contribute anyways.

 I love Django. I love Open Source. I love all the people that contribute
 to this stuff. Honestly Do.

 So here is the way I found to do this a little easier.

 http://stackoverflow.com/questions/4938491/django-admin-change-header-
 django-administration-text

--

--
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/072.b585f6fe3ca8cff6735f92fb79f0bb9b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23573: Templates override with Admin Site TEMPLATE_DIRS wrong way

2014-09-30 Thread Django

#23573: Templates override with Admin Site   TEMPLATE_DIRS  wrong way
-+-
 Reporter:  hernandocounty   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.7
Component:  Template system  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  TEMPLATES_DIR|  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 With such language, you are not going to go very far. If you really want
 to make a constructive contribution to the Django project, which is run
 through volunteers, please reopen a new ticket, change your language and
 describe politely what you are suggesting to improve in the Django
 documentation. Or just use another framework with better documentation.

--
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/072.e9a0543993c8ebb4ef50b8c8af9c6867%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23573: Templates override with Admin Site TEMPLATE_DIRS wrong way

2014-09-30 Thread Django

#23573: Templates override with Admin Site   TEMPLATE_DIRS  wrong way
-+-
 Reporter:  hernandocounty   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.7
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  TEMPLATES_DIR|  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by hernandocounty):

 * cc: hernandocounty (added)
 * needs_docs:   => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 https://docs.djangoproject.com/en/1.7/intro/tutorial02/

 this page has bad info


 this page is how I finally changed the text on the admin interface.

 http://stackoverflow.com/questions/4938491/django-admin-change-header-
 django-administration-text

--
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/072.7b8dcc037ad8e94e7ca3e5527bf8b50d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23574: Makemigrations tries to migrate non-model classes

2014-09-30 Thread Django

#23574: Makemigrations tries to migrate non-model classes
+--
 Reporter:  shredding   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 shredding):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 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/067.05806bd530c453baccf7ca17fbfb4bcb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23574: Makemigrations tries to migrate non-model classes

2014-09-30 Thread Django

#23574: Makemigrations tries to migrate non-model classes
---+
 Reporter:  shredding  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If your model extends non-model classes, the migration fails with:

 raise ValueError("Cannot serialize: %r\nThere are some values Django
 cannot serialize into migration files.\nFor more, see
 https://docs.djangoproject.com/en/dev/topics/migrations/#migration-
 serializin

 The reason is that before adding the base classes there is no check if the
 base class is indeed a django model:

 
https://github.com/django/django/blob/master/django/db/migrations/autodetector.py#L495-505

 Solution: Check if the base class is an instance of django.db.model before
 adding it.

 Context:

 I have Models with some mixins that just add method and functionality that
 is shared among multiple models, e.g. an InvoiceMixin, that is shared by
 multiple models to enrich them with convenience methods.

--
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.0bb98be71b7def2f0a1ac01a05951785%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23573: Templates override with Admin Site TEMPLATE_DIRS wrong way

2014-09-30 Thread Django

#23573: Templates override with Admin Site TEMPLATE_DIRS wrong way
--+---
Reporter: hernandocounty| Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Template system |Version: 1.7
Severity: Normal| Keywords: TEMPLATES_DIR
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+---
this is the way I finally got this done. After almost 2 days guys.
Django Project this is unacceptable. We pride ourselves in DRY and
documentation but on version 1.7 Tutorial you tell the absolute WRONG WAY
to change the look of the ADMIN SITE.

http://stackoverflow.com/questions/4938491/django-admin-change-header-
django-administration-text

this is the only way I got it to work ...

by editing urls.py not by loading TEMPLATE blah blah and os.path.join
crap and all this two days of my life wasted on SHIT Documenation guys
the 1.7 examples are no good . Part two of Tutorial of change the
look of admin site with TEMPLATE_DIRS that stuff doesnt work.

I love this project. But you guys know as well as I do, this is not OK.

Thanks

Doug

--
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/057.413e9fd31ba9ad61aaba595a60731445%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23423: Integrate unaccent lookups in django.contrib.postgres

2014-09-30 Thread Django

#23423: Integrate unaccent lookups in django.contrib.postgres
--+
 Reporter:  tchaumeny |Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * needs_docs:  0 => 1


Comment:

 Marking as "patch needs improvement" (pending bilateral transform) and
 "needs documentation".

--
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.4c3b68b07edcc4cc2550f1da2ee3f060%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #7361: Add back button to admin delete page

2014-09-30 Thread Django

#7361: Add back button to admin delete page
-+-
 Reporter:  simon|Owner:  barbuza
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  usability nfa-   | Triage Stage:  Accepted
  someday feature|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"f5cfd09c257e5a4ed6d01d32505c48b02e3860d5"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5cfd09c257e5a4ed6d01d32505c48b02e3860d5"
 Fixed #7361 -- Added cancel link to admin delete views.
 }}}

--
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.452764190dc1ff40803a9f8cf0fd114c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] f5cfd0: Fixed #7361 -- Added cancel link to admin delete v...

2014-09-30 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f5cfd09c257e5a4ed6d01d32505c48b02e3860d5
  
https://github.com/django/django/commit/f5cfd09c257e5a4ed6d01d32505c48b02e3860d5
  Author: Nick Sandford 
  Date:   2014-09-30 (Tue, 30 Sep 2014)

  Changed paths:
M django/contrib/admin/static/admin/css/base.css
M django/contrib/admin/templates/admin/delete_confirmation.html
M django/contrib/admin/templates/admin/delete_selected_confirmation.html
M tests/admin_views/tests.py

  Log Message:
  ---
  Fixed #7361 -- Added cancel link to admin delete views.


-- 
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/542aa61ca1b61_73963fce1d88b2bc76531%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22879: Database errors coming from cursor iterator are not converted to Django database errors

2014-09-30 Thread Django

#22879: Database errors coming from cursor iterator are not converted to Django
database errors
-+-
 Reporter:  denisenkom@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by tchaumeny):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 As discussed on https://github.com/django/django/pull/2839, the patch
 could be simplified a bit.

--
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.f85cf3d5287eb7184afc30182f4ef370%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23570: Schema editor drops DEFAULT from columns for backends that do support it

2014-09-30 Thread Django

#23570: Schema editor drops DEFAULT from columns for backends that do support it
-+-
 Reporter:  mpessas  |Owner:  mpessas
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  assigned => closed
 * resolution:   => invalid


Comment:

 The idea is that Django shouldn't leave `DEFAULT` values in the database
 (see #23043). A default is only used in the `ADD COLUMN` SQL so that a
 field can be added as non-null.

--
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.66d1acd84bbfb272d7e64c43bc1ae57a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23572: Exception on Custom Lookups when right value is None.

2014-09-30 Thread Django

#23572: Exception on Custom Lookups when right value is None.
-+-
 Reporter:  maherma-adg  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  custom lookup, db|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 Yes, it seems this check belongs to the Lookup (with a base implementation
 that raises the ValueError).

 BTW you are likely going to stumble upon some other limitations in the
 current Lookup implementation. A `.exclude(duration__ne=None)` call might
 not work as expected (that is, return complement of
 `.filter(duration__ne=None)`).

--
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/069.d10e8d5c25efcdafc2c04df7aa0a408a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23572: Exception on Custom Lookups when right value is None.

2014-09-30 Thread Django

#23572: Exception on Custom Lookups when right value is None.
--+
 Reporter:  maherma-adg   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:  custom lookup,
 Triage Stage:  Unreviewed|  db
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 For my current project I need generate a complex queryset filter and I
 decide implement as custom lookup.

 I got the [https://docs.djangoproject.com/en/1.7/howto/custom-lookups/,
 example] as base to create custom lookup, but during test, this expresion:

 data = Rsce.filter(duration{{{__}}}ne = None)

 throw an exception. Any other expresion run smoothly.

 Looking into code exception are thrown in this piece of code:


 if value is None:
 if lookups[-1] not in ('exact', 'iexact'):
 raise ValueError("Cannot use None as a query value")

 IMHO the check in lookups must be avoided on custom lookups, allowing them
 to manage None values by themselves.

--
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/054.c8ea9250e668cd1b63c4286c7c4bd493%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23571: Empty order_by() doesn't work with slice

2014-09-30 Thread Django

#23571: Empty order_by() doesn't work with slice
--+
 Reporter:  liminspace|  Owner:  liminspace
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:  order_by,
 Triage Stage:  Unreviewed|  slice
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 MyModel.objects.order_by() - use SQL without ORDER BY.
 MyModel.objects.order_by()[:10] - use SQL with ORDER BY (default fields
 for model ordering).

 This is a bug or a feature? :)

--
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.feca9e16ac2dc49eab8a0ff17cdefee9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15089: contrib.sites and multitenancy

2014-09-30 Thread Django

#15089: contrib.sites and multitenancy
---+
 Reporter:  legutierr  |Owner:  apollo13
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:
 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
---+

Comment (by rm_):

 ↑ Forward ported the patch to apply cleanly against latest git 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/067.0a37012bddd8d5ed8d7bdadb9a3dfa34%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19544: IntegrityError during Many To Many add()

2014-09-30 Thread Django

#19544: IntegrityError during Many To Many add()
-+-
 Reporter:  Kronuz   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I don't think comment:11 is talking about this ticket's issue (that is, it
 is not about m2m add()).

--
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.58e3100dd7cb578d3adda8c7d9d71aec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

56 matches

Mail list logo