[Django] #19628: Add to the documentation note about AUTH_USER_MODEL

[Django]

#19628: Add to the documentation note about AUTH_USER_MODEL
---+
 Reporter:  dpravdin   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.5-beta-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 It's problem, that if I write the User model striсtly for documentation, I
 will get a validation error:
 {{{
 auth.user: Model has been swapped out for 'myapp.MyUser' which has not
 been installed or is abstract.
 }}}
 It's not enough just to set
 {{{
 AUTH_USER_MODEL = 'myapp.MyUser'
 }}}
 Beside that it's necessary add the 'myapp' in INSTALLED_APPS, but it's not
 specified in the documentation.


 Sorry, if it's specified but I didn't find it :)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9368: Clean up code for getting columns for select query

[Django]

#9368: Clean up code for getting columns for select query
-+-
 Reporter:  adunar   |Owner:
 Type:   |  mtredinnick
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I did some investigation some time ago for rewriting the cols output code
 - the code is available from
 https://github.com/akaariai/django/compare/dedupe_cols.

 The original idea was to have just "col" syntax instead of
 "tbl_alias"."col" syntax unless the col is duplicated in some other table.
 This would result in much nicer looking SQL. However, this approach has a
 fundamental problem: We don't actually know all the cols in a table, just
 those the user has in the models. At the least we would need some way for
 the user to tell that this table has these extra cols, even if they are
 not part of the model definition. Otherwise we will break existing code
 with no upgrade path at all.

 After the dedupe cols experiment I hacked a bit more, and the changes
 ended happening all-around. So, the branch isn't meant for inclusion.
 Still, I think the code could be useful as a reference point if somebody
 decides to tackle this issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

[Django]

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
-+-
 Reporter:  ikelly   |Owner:
 Type:   |  mtredinnick
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I just verified that this we still generate extra queries in this case.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9519: Add QuerySet.bulk_delete() that issues only a single SQL query

[Django]

#9519: Add QuerySet.bulk_delete() that issues only a single SQL query
-+-
 Reporter:  Tarken   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  database, queryset,  |  Needs documentation:  0
  delete |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 Do we still want this? The deletion code is now intelligent enough to do
 fast-path deletion where possible. We could improve it by having
 "no_signals" arg, and making it only fetch values() for cascade columns if
 there is no need for sending the signals (latter is likely tricky to do).

 We should not have a delete which does not respect cascades along foreign
 keys. Some DBs do not enforce the foreign keys so this would be a real
 gun-pointed-at-foot.

 I'm inclined to close this as wontfix...

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9049: queryset .extra(tables=[...]) unnecessarily quotes table names

[Django]

#9049: queryset .extra(tables=[...]) unnecessarily quotes table names
-+-
 Reporter:  tobias   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:  wontfix
 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 akaariai):

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


Comment:

 Seems like no action in 4 years for a reference point ticket is a good
 reason for closing.

 It would be nice to have an easy way to inject subqueries into ORM
 queries, but .extra() I don't think we want to push .extra() in that
 direction.

 Maybe we would want to add a generic "mark_safe" style way to avoid
 quoting of names. This would be useful for example in:

 {{{
 class SomeView(models.Model):
 cols...

 class Meta:
 db_table = mark_safe("(select * from sometable join othertable)")
 managed = False
 }}}
 Suddenly, you have inlined view! Would also solve this ticket's issue.

 But, not this ticket's issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8946: Denormalisation built in to the ORM

[Django]

#8946: Denormalisation built in to the ORM
-+-
 Reporter:  simon|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  djangocon|  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

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


Comment:

 I'm going to close this. Reasons:
   - It seems this could be implemented perfectly well in 3rd party apps
 (with maybe some added hooks in core)
   - This seems really, really hard to do in cross-db compliant way,
 supporting all the different ORM queries we have (update() etc), and with
 concurrency tackled. Raw SQL would get past us in any case
   - There are different use cases which would benefit from different
 approaches, again pointing to 3rd party apps
   - No action in 4 years
   - This ticket doesn't have much useful information

 If somebody has plans do something about this, please reopen.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18062: Document Best Practice for Choices in Model Fields

[Django]

#18062: Document Best Practice for Choices in Model Fields
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by charettes):

 It looks like we should also update
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /coding-style/#model-style model coding styles] to reflect this.

 The part about `choices` contradicts best practices:
 {{{
 If choices is defined for a given model field, define the choices as a
 tuple of tuples, with an all-uppercase name, either near the
 top of the model module or just above the model class.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19399: Do not recreate RelatedObject instances

[Django]

#19399: Do not recreate RelatedObject instances
-+-
 Reporter:  KJ   |Owner:  KJ
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * has_patch:  1 => 0
 * easy:  1 => 0
 * stage:  Ready for checkin => Accepted


Comment:

 I committed the validation and caching changes, without the tests.

 Personally, I don't think the tests add that much value. They test 3
 specific places for not creating RelatedObject instances, but we have
 still the rest of codebase uncovered. It is impossible to test that
 RelatedObjects aren't recreated anywhere in the codebase by testing
 specific places for that. In addition, if we ever decide to alter the
 underlying implementations, the tests would be noise errors. (I am
 currently wondering why we need both field.rel and field.related. Seems
 strange...).

 I also removed the self.rel_name line from the forms/models.py. It is
 dead-code.

 I don't feel comfortable doing the alternatebook name change. It *will*
 break existing public-API using code, at least tests, as we change what
 values can be passed in the request.POST. Those using public APIs are more
 important than those who want to hack with the internals.

 So, leaving this open if you want to tackle the AlternateBook issue. It
 doesn't seem to be an easy one to tackle.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19399: Do not recreate RelatedObject instances

[Django]

#19399: Do not recreate RelatedObject instances
-+-
 Reporter:  KJ   |Owner:  KJ
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by Anssi Kääriäinen ):

 In [changeset:"3647c0a49a2f4535b8a9aba40e662743e4d53e76"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3647c0a49a2f4535b8a9aba40e662743e4d53e76"
 Avoided unnecessary recreation of RelatedObjects

 Refs #19399. Thanks to Track alias KJ for the patch.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 3647c0: Avoided unnecessary recreation of RelatedObjects

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3647c0a49a2f4535b8a9aba40e662743e4d53e76
  
https://github.com/django/django/commit/3647c0a49a2f4535b8a9aba40e662743e4d53e76
  Author: Anssi Kääriäinen 
  Date:   2013-01-17 (Thu, 17 Jan 2013)

  Changed paths:
M django/core/management/validation.py
M django/db/models/options.py
M django/forms/models.py

  Log Message:
  ---
  Avoided unnecessary recreation of RelatedObjects

Refs #19399. Thanks to Track alias KJ for the patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17181: Allow for specifying multiple locales and domains for makemessages and compilemessages commands

[Django]

#17181: Allow for specifying multiple locales and domains for makemessages and
compilemessages commands
-+-
 Reporter:  aminland |Owner:  jakul
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.3
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  i18n makemessages|  Needs documentation:  0
  compilemessages|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by ramiro):

 Also, I see I've not given credit  in the commit message to contributor
 aminland who is the original author of the code. Thank you for your great
 work and please excuse my error.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #3361: Create Database Views from the Model

[Django]

#3361: Create Database Views from the Model
-+-
 Reporter:  martin.marcher@… |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bignose):

 * cc: bignose (added)
 * type:  Uncategorized => New 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17181: Allow for specifying multiple locales and domains for makemessages and compilemessages commands

[Django]

#17181: Allow for specifying multiple locales and domains for makemessages and
compilemessages commands
-+-
 Reporter:  aminland |Owner:  jakul
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.3
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  i18n makemessages|  Needs documentation:  0
  compilemessages|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by ramiro):

 * status:  new => closed
 * resolution:   => fixed
 * stage:  Fixed on a branch => Accepted


Comment:

 Initial plan was to split the work for the features proposed in the PR in
 two parts:

 a. Add support for multiple locales to makemessages and compilemessages
 (already done)
 b. Add support for multiple gettext domains to makemessages

 Regarding feature b:

 I found the proposed patch/PR is buggy regarding handling of multiple
 domains and the file extensions to be processed as pertaining to each one
 of these domains. Found this while adding tests for the functionality that
 were missing from the PR.

 IMO the new functionality isn't worth the trouble both in terms of support
 code (relatively simple) and in terms of the command line switches UI
 needed to allow the user to express arbitrary combinations of domains plus
 their sets of file extensions.

 Conclusion: I'm closing this ticket as fixed having only implemented
 feature a.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #3361: Create Database Views from the Model

[Django]

#3361: Create Database Views from the Model
-+-
 Reporter:  martin.marcher@… |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bignose):

 * status:  closed => new
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #3361: Create Database Views from the Model

[Django]

#3361: Create Database Views from the Model
-+-
 Reporter:  martin.marcher@… |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bignose):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Setting `managed = False` on a model does not meet this need.

 A database view created by Django's `syncdb` will allow the application to
 be deployed without special steps. This is not satisfied by an unmanaged
 model.

 A database view created by Django's `syncdb` will create the entity in the
 test database, allowing app code to use that view without breaking tests.
 This is not satisfied by an unmanaged model.

 Re-opening, since this is not a duplicate of #3163.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19399: Do not recreate RelatedObject instances

[Django]

#19399: Do not recreate RelatedObject instances
-+-
 Reporter:  KJ   |Owner:  KJ
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by KJ):

 The user asks for AlternateBook when creating inline formset, but foreign
 key is created on Book. Author class doesn't know anything about
 AlternateBook class being tied to it. So if we ask what will happen if we
 have two subclasses of Book with inline formsets, then this situation is
 roughly equivalent to creating two inline formsets for Book class, and
 similar problems will occur. If there is really separate logic tied to
 AlternateBook, maybe separate foreign key should be created, but these are
 just my loose thoughts, not strict reasoning.

 If we however decide to preserve AlternateBook formset prefixes, I will
 argue to change the method of generating them. Current implementation
 doesn't use RelatedObject from AlternateBook, which was created for Book
 class and returns 'book-' prefixes. Instead of it another RelatedObject is
 created to obtain different prefix, but the original one remains inside
 AlternateBook class. This is tricky and may be misleading — if we already
 have one RelatedObject inside AlternateBook class, then we should stick to
 it.

 I've updated the pull request to fix a typo reported in comment. Commit
 hash is now 6cfb8a8a506b2c.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19627: Silly little thing but could lead to confusion

[Django]

#19627: Silly little thing but could lead to confusion
-+--
 Reporter:  kaceyandlenny@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 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 timo):

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


Comment:

 I've backported the fix from #19555 to 1.4.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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19555: tutorial pt 1 - update year for examples to work

[Django]

#19555: tutorial pt 1 - update year for examples to work
--+
 Reporter:  rodrigorosa.lg@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  year  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"89ba1b27b4442cbb43555f607ab7d0f189a2af50"]:
 {{{
 #!CommitTicketReference repository=""
 revision="89ba1b27b4442cbb43555f607ab7d0f189a2af50"
 [1.4.x] Fixed #19555 - Removed '2012' from tutorial 1.

 Thanks rodrigorosa.lg and others for the report.

 Backport of 99315f709e from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 89ba1b: [1.4.x] Fixed #19555 - Removed '2012' from tutoria...

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 89ba1b27b4442cbb43555f607ab7d0f189a2af50
  
https://github.com/django/django/commit/89ba1b27b4442cbb43555f607ab7d0f189a2af50
  Author: Tim Graham 
  Date:   2013-01-17 (Thu, 17 Jan 2013)

  Changed paths:
M docs/intro/tutorial01.txt

  Log Message:
  ---
  [1.4.x] Fixed #19555 - Removed '2012' from tutorial 1.

Thanks rodrigorosa.lg and others for the report.

Backport of 99315f709e from master



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ab6ff2: Fixed i18n test to match changed translation

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: ab6ff2e0ac3a059c890d84a7a8b8f8646ddbbd4f
  
https://github.com/django/django/commit/ab6ff2e0ac3a059c890d84a7a8b8f8646ddbbd4f
  Author: Claude Paroz 
  Date:   2013-01-17 (Thu, 17 Jan 2013)

  Changed paths:
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  Fixed i18n test to match changed translation



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by jeremyt):

 Pull Request created [https://github.com/django/django/pull/656]

 I haven't made changes for previous comment yet but just pulled what I
 have committed. I will move the ForeignKeyEx out and placing the
 functionality as 'JoinField' which will always be the type of field for
 PathInfo.join_field. Please comment away and I will continuously integrate
 them.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19627: Silly little thing but could lead to confusion

[Django]

#19627: Silly little thing but could lead to confusion
-+
 Reporter:  kaceyandlenny@…  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Documentation|Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The tutorial (https://docs.djangoproject.com/en/1.4/intro/tutorial01/) in
 the second half of the Django API section suggests typing
 Poll.objects.get(pub_dat__year = 2012). I know it has only been about two
 weeks but this should be changed to 2013. It only took me a minute or two
 to figure this one out, lol but it may take others longer.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19626: No module named django.views.generic.simple in 1.5c1

[Django]

#19626: No module named django.views.generic.simple in 1.5c1
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Generic views  |  Version:  1.5-beta-1
 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 timo):

 * status:  new => closed
 * resolution:   => invalid
 * severity:  Release blocker => Normal


Comment:

 It's mentioned in the Deprecation Timeline:
 https://docs.djangoproject.com/en/dev/internals/deprecation/ under 1.5
 ("The function-based generic view modules will be removed in favor of
 their class-based equivalents") as well as the 1.3 release notes when
 these functions were originally deprecated:
 https://docs.djangoproject.com/en/dev/releases/1.3/#function-based-
 generic-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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19626: No module named django.views.generic.simple in 1.5c1

[Django]

#19626: No module named django.views.generic.simple in 1.5c1
-+--
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  1.5-beta-1
 Severity:  Release blocker  |   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 epandurski@…):

 * needs_better_patch:   => 0
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19626: No module named django.views.generic.simple in 1.5c1

[Django]

#19626: No module named django.views.generic.simple in 1.5c1
-+
 Reporter:  anonymous|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Generic views|Version:  1.5-beta-1
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I have this line in my urls.py:

 from django.views.generic.simple import redirect_to

 Django breaks with: "No module named simple".

 I guess this means that django.views.generic.simple is not available in
 1.5 anymore. This is a backward incompatible change. But this is not
 mentioned in in the release notes.

 Here is the traceback:

 Environment:


 Request Method: GET
 Request URL: http://localhost:8000/

 Django Version: 1.5c1
 Python Version: 2.7.3
 Installed Applications:
 ('django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'cmbarter.users',
  'cmbarter.profiles',
  'cmbarter.products',
  'cmbarter.deposits',
  'cmbarter.deals',
  'cmbarter.orders',
  'cmbarter.mobile')
 Installed Middleware:
 ('django.middleware.gzip.GZipMiddleware',
  'django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.locale.LocaleMiddleware')


 Traceback:
 File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py"
 in get_response
   92. response = middleware_method(request)
 File "/usr/local/lib/python2.7/dist-packages/django/middleware/locale.py"
 in process_request
   21. check_path = self.is_language_prefix_patterns_used()
 File "/usr/local/lib/python2.7/dist-packages/django/middleware/locale.py"
 in is_language_prefix_patterns_used
   54. for url_pattern in get_resolver(None).url_patterns:
 File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py"
 in url_patterns
   347. patterns = getattr(self.urlconf_module, "urlpatterns",
 self.urlconf_module)
 File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py"
 in urlconf_module
   342. self._urlconf_module = import_module(self.urlconf_name)
 File "/usr/local/lib/python2.7/dist-packages/django/utils/importlib.py" in
 import_module
   35. __import__(name)
 File "/home/evgeni/cmb/cmbarter/../cmbarter/urls.py" in 
   31. from django.views.generic.simple import redirect_to

 Exception Type: ImportError at /
 Exception Value: No module named simple

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15295: GeoDjango model creation fails for MySQL during tests

[Django]

#15295: GeoDjango model creation fails for MySQL during tests
+
 Reporter:  adamnelson  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Cerin):

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


Comment:

 Please re-consider this bug. It effects a lot more than just tests. As
 most people use Innodb with MySQL, this effectively makes all
 django.contrib.gis functionality incredibly awkward to most MySQL users,
 if not completely inaccessible. Slower functionality due to missing
 indexes on Innodb is preferrable to  no functionality whatsoever.

 It should at least be mentioned in the docs somewhere that GeoDjango has
 not support for InnoDB. I wasted several hours going over the docs and
 through the setup only to realize I couldn't use any of it with my pre-
 existing InnoDB database when my initial model migrations blew up.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14342: Part 2 of the Tutorial -- path format for TEMPLATE_DIR

[Django]

#14342: Part 2 of the Tutorial -- path format for TEMPLATE_DIR
---+--
 Reporter:  nwokedi|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.2
 Severity:  Normal |   Resolution:  worksforme
 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 timo):

 TEMPLATE_DIRS should be a list of directories, not files.  So you would
 want 'C:/Users/BernardWork/Documents/Work/WebStuff/mysite/admin/' in your
 TEAMPLATE_DIRS. But, please don't use the ticket system for support
 issues.  Please see https://docs.djangoproject.com/en/dev/#getting-help

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15742: Bug: Mark all does not contain full queryset when using intermidiate pages in Django admin

[Django]

#15742: Bug: Mark all does not contain full queryset when using intermidiate 
pages
in Django admin
-+-
 Reporter:  Herman S |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Documentation|   Resolution:
 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|
-+-

Comment (by anonymous):

 I found similar problem.

 In admin class of some object I set list_editable attribute. Open change-
 list page. Make some changes. If in site's users-side some object was
 added between you open admin change-list page and click save button, last
 objects of current page in admin page will not correctly save.

 I solved this problem removing
 queryset=cl.result_list
 in django/contrib/admin/options.py at 1184 line

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14342: Part 2 of the Tutorial -- path format for TEMPLATE_DIR

[Django]

#14342: Part 2 of the Tutorial -- path format for TEMPLATE_DIR
---+--
 Reporter:  nwokedi|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.2
 Severity:  Normal |   Resolution:  worksforme
 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 sheridb3@…):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Hi there

 I am having a similar problem. I have the following absolute path in the
 TEMPLATE_DIRS in settings.py:
 C:/Users/BernardWork/Documents/Work/WebStuff/mysite/admin/base_site.html

 with base_site.html containing the edited admin name but the
 django.template.loaders.filesystem.Loader seems to be ignoring this path
 and using the location of the django source could base_site.html page. But
 when put inside my project mysite/polls/templates/admin it works and I
 know this is using the
 django.template.loaders.app_directories.load_template_source but it works
 while the other doesnt and I followed all instructions to the T. If you
 could get back to me on where I am going wrong I would really appreciate
 it. I am using a Windows 7 32- bit system and django 1.4.2 and python 2.7.

 Many Thanks

 Bernard

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17854: Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend

[Django]

#17854: Problem with DecimalField and big vlues of max_digits, decimal_places,
sqlite3 backend
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  DecimalField bug |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by wdoekes):

 Never mind my comments. They belong in a different ticket: #19625

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19625: mysql 5.1 large decimalfield lookups return too few results

[Django]

#19625: mysql 5.1 large decimalfield lookups return too few results
--+
 Reporter:  wdoekes   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 It seems that there is a bug in the mysql 5.1 (and probably lower)
 conversion of strings to decimals. Since Decimal value lookups are always
 passed to the mysql backend as strings, Django is affected.

 See this example:
 {{{
 mysql> select version() as server_version\G
 *** 1. row ***
 server_version: 5.1.66-0+squeeze1-log
 ...
 mysql> create table abc (value decimal(31,0));
 ...
 mysql> insert into abc values (1234567890123456789012345678901);
 Query OK, 1 row affected (0.00 sec)

 mysql> select value from abc where value =
 1234567890123456789012345678901\G
 *** 1. row ***
 value: 1234567890123456789012345678901
 ...

 mysql> select value from abc where value =
 '1234567890123456789012345678901'\G
 Empty set (0.01 sec)
 }}}

 Obviously, a fix could be to upgrade to a newer MySQL server version --
 the MySQL 5.5.28 I tested didn't have this issue -- but that isn't always
 possible.

 I suppose a workaround/fix might not be included in Django because the bug
 lies in MySQL, but I'll file it here for the record.

 Test cases are included:
 {{{
 FAIL: test_decimal_field_broken1 (test_long_decimal.tests.DecimalTests)
 ...
 AssertionError: book with isbn 1234567890123456789012345678901 was not
 found
 }}}

 I tried to work around the bug by surrounding a decimal value in lookup
 with CAST(..), but that (sometimes!) triggers an SQL Warning (in other
 tests!) instead:
 {{{
 ERROR: test_decimal_field_works1 (test_long_decimal.tests.DecimalTests)
 ...
 Warning: Truncated incorrect DECIMAL value: ''
 }}}

 So, my easy fix did not work out as expected.

 The proper fix, if any, would probably to force the backend to take the
 decimal as an *unquoted* value. But I didn't find an easy path to achieve
 that.

 Regards,
 Walter Doekes
 OSSO B.V.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19623: Update inlines.js to use jQuery 1.9

[Django]

#19623: Update inlines.js to use jQuery 1.9
-+-
 Reporter:  jordanorc|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  jquery admin | Triage Stage:
  inlines.js |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jordanorc):

 Yes... Is the same bug. Sorry for that. The patch can be attached to issue
 #19598, if necessary.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.