Re: [Django] #24856: raw_id_fields popup missing

[Django]

#24856: raw_id_fields popup missing
---+--
 Reporter:  liwee  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.8
 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 liwee):

 I see, yes, I am using django-grappelli.

 Ran a few more tests on the clean project (without django-grappelli)
 1. work in IE 11
 2. work in chrome (incognito mode)
 3. does not work in chrome (normal mode)

 Since the same behaviour occurred initially when I created a clean
 project, it did not even occur to me that django-grappelli could be the
 culprit. Appreciate the advice. Thank you.

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

[Django] #24896: Clickjacking doc doesn't specify middleware/view decorator behaviour when X-Frame-Options header is already set.

[Django]

#24896: Clickjacking doc doesn't specify middleware/view decorator behaviour 
when X
-Frame-Options header is already set.
--+
 Reporter:  wsot  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 On the page https://docs.djangoproject.com/en/1.8/ref/clickjacking/ it is
 not specified what the behaviour of the view decorators and middleware is
 when the X-Frame-Options HTTP header is already present.
 (The behaviour is that if the header is already present, it is left
 unmodified)

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

Re: [Django] #9596: Add a __date lookup for DateTimeField

[Django]

#9596: Add a __date lookup for DateTimeField
-+-
 Reporter:  django@… |Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  lookup_type date | Triage Stage:  Accepted
  datetimefield compare comparison   |
  query_term field lookup|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jdufresne):

 * needs_better_patch:  1 => 0


Comment:

 Updated patch for Oracle based on feedback. All tests are now passing.

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

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

Re: [Django] #24893: Django migrations don't add unique constraint for field that is changed from primary_key to unique

[Django]

#24893: Django migrations don't add unique constraint for field that is changed
from primary_key to unique
-+-
 Reporter:  jbzdak   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Release blocker  |   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):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4733 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/064.cedea4b2d1a4012709ae5f075967e16c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24856: raw_id_fields popup missing

[Django]

#24856: raw_id_fields popup missing
---+--
 Reporter:  liwee  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.8
 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 timgraham):

 Are you using any third-party apps? "grp" in the JavaScript console
 suggests django-grappelli to me. The string "grp" doesn't exist in the
 Django repo.

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

Re: [Django] #24856: raw_id_fields popup missing

[Django]

#24856: raw_id_fields popup missing
---+--
 Reporter:  liwee  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.8
 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 liwee):

 The popup works in IE 11.

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

Re: [Django] #24628: Squash migration is not marked as applied when the migrations it replaces are (was: Cannot apply migration that depends on squashed migration)

[Django]

#24628: Squash migration is not marked as applied when the migrations it 
replaces
are
+
 Reporter:  dwt |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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
+

Old description:

> After some time in the chat with MarkusH, we decided that this should be
> a bug report.
>
> Some context: I have quite some migrations (33) of which the first
> already was a squash of several migrations. It did get it's 'replaced'
> field removed though, as the original migrations it replaced are long
> gone already. The goal now was to get that long list of migrations down
> to one again, for peace of mind.
>
> This led to the following symptoms: When I created the squashed migration
> everything seemed fine. ./manage.py migrate did say that nothing was to
> be done (but then again, all the migrations to be squashed where already
> applied).
>
> But adding another migration after that ended in tears - ./manage migrate
> didn't want to apply it and told me so in no uncertain terms.
>
> {{{
> (pycess)dwt@atlan ~/Code/Projekte/pycess/pycess (git)-[master] %
> ./manage.py migrate
> Traceback (most recent call last):
>   File "./manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/core/management/__init__.py",
> line 330, in execute_from_command_line
> utility.execute()
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/core/management/__init__.py",
> line 322, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/core/management/base.py",
> line 347, in run_from_argv
> self.execute(*args, **cmd_options)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/core/management/base.py",
> line 398, in execute
> output = self.handle(*args, **options)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/core/management/commands/migrate.py",
> line 86, in handle
> executor = MigrationExecutor(connection,
> self.migration_progress_callback)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/db/migrations/executor.py",
> line 19, in __init__
> self.loader = MigrationLoader(self.connection)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/db/migrations/loader.py",
> line 47, in __init__
> self.build_graph()
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/db/migrations/loader.py",
> line 281, in build_graph
> _reraise_missing_dependency(migration, parent, e)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/db/migrations/loader.py",
> line 264, in _reraise_missing_dependency
> raise exc
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/db/migrations/loader.py",
> line 274, in build_graph
> self.graph.add_dependency(migration, key, parent)
>   File
> "/Users/dwt/Code/Projekte/pycess/django/django/db/migrations/graph.py",
> line 124, in add_dependency
> parent
> django.db.migrations.graph.NodeNotFoundError: Migration
> process.0002_auto_20150411_1005 dependencies reference nonexistent parent
> node ('process', '0001_squashed_initial_2')
> }}}
>
> Here we had quite some discussion in #django-dev with MarkusH, of which
> the result to me was that a) django doesn't seem to ever record that a
> squashed migration is applied, at least as long as it is recognizable by
> django as a squashed migration (i.e. it has a .replaced property). b)
> there seems to be no way to tell django that the replacing squashed
> migration really is already applied for this database.
>
> The last one turned out to be achievable if you remove the old migrations
> and the .replaces property from the squashed migration and then apply it
> with --fake
>
> MarkusH might want to say more here that he can describe better.
>
> For ease of reproduction I'm attaching the project where this occurred
> for me.

New description:

 (I am attempting a shorter and clearer description of this bug, but
 leaving the original description intact below - carljm).

 In Django 1.8, consider an app `A` with migrations `1` and `2` and a
 squashed migration `1_squashed_2` that replaces both `1` and `2`. Consider
 a deployment of this app which has only `1` applied. When it receives the
 update including `2` and `1_squashed_2` and is migrated, `2` is marked as
 applied in the database but `1_squashed_2` is not.

 This does not immediately appear to be a problem, because as long as
 migrations `1` and `2` exist and `1_squa

Re: [Django] #24837: Unable to query DateField using DateRange

[Django]

#24837: Unable to query DateField using DateRange
--+
 Reporter:  schinckel |Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by schinckel):

 I know it _should_ just work, but is it worth having tests for
 {{{.exclude(...__contained_by=...)}}} worthwhile?

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

Re: [Django] #24837: Unable to query DateField using DateRange

[Django]

#24837: Unable to query DateField using DateRange
--+
 Reporter:  schinckel |Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by schinckel):

 Hmm. Is casting a datetime to a date (i.e., in python doing a
 {{{.date()}}}) going to give the same result as doing the comparison in
 the database with a datetime (contained by a daterange)?

 My gut feeling is yes, but I may not have had enough coffee this morning
 to make an educated guess.

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

Re: [Django] #24895: Migration loader fails to load pair of squashed apps when dependent app's squashed migrations are partially applied

[Django]

#24895: Migration loader fails to load pair of squashed apps when dependent 
app's
squashed migrations are partially applied
+--
 Reporter:  carljm  |Owner:  carljm
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.8
 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 carljm):

 * owner:  nobody => carljm
 * status:  new => assigned
 * has_patch:  0 => 1


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

Re: [Django] #24895: Migration loader fails to load pair of squashed apps when dependent app's squashed migrations are partially applied

[Django]

#24895: Migration loader fails to load pair of squashed apps when dependent 
app's
squashed migrations are partially applied
+--
 Reporter:  carljm  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by carljm):

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

 Rather than trying to detect whether the replacement in question will
 actually occur (which duplicates logic that will occur when that
 replacement is itself processed), we just update the dependencies of every
 migration that depends on this one, replacing or replaced. This means we
 may update the dependencies of a migration that won't in the end be used,
 but there's no harm in that; better to keep more state accurate than less.

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

Re: [Django] #24837: Unable to query DateField using DateRange

[Django]

#24837: Unable to query DateField using DateRange
--+
 Reporter:  schinckel |Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by mjtamlyn):

 I've made some progress, see
 https://github.com/django/django/compare/master...mjtamlyn:query-with-
 ranges

 There is no operator for `not_contained_by` in postgres so I removed that
 pseudocode from schinckel's branch.

 The code passes the tests but needs some serious tidying up to cover non-
 simple use cases (F objects, complex expressions with output types etc).
 Sadly a lot of explicit typecasting is required to make postgres not freak
 out. As a result, I think we likely should just support "matching"
 operations. For example this means big integer in a big integer range,
 datetime in a datetime range not a date range.

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

[Django] #24895: Migration loader fails to load pair of squashed apps when dependent app's squashed migrations are partially applied

[Django]

#24895: Migration loader fails to load pair of squashed apps when dependent 
app's
squashed migrations are partially applied
--+
   Reporter:  carljm  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  1.8
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Consider the following set of migrations (taken directly from the test
 suite; for clarity I removed the repetitive `_auto` suffix from the
 migration names, and renamed the apps `A` and `B` instead of `app1` and
 `app2`):

 app `A`: `1` -> `2` -> `3` -> `4`
 app `B`: `1` -> `2`

 Where `A.3` has a dependency on `B.2`, and there also exist two squashed
 migrations `A.2_squashed_3` and `B.1_squashed_2`.

 If `A.2` and `A.3` are both applied or unapplied (that is, their
 replacement by `A.2_squashed_3` is allowed to take effect), this migration
 set will load fine.

 But if `A.2` is applied and `A.3` is not, this migration set will fail to
 load with "django.db.migrations.exceptions.NodeNotFoundError: Migration
 A.3 dependencies reference nonexistent parent node ('B', '2')".

 When the loader iterates over all "replacing" migrations, it finds
 `B.1_squashed_2`. Then it looks at each migration replaced by
 `B.1_squashed_2`, and one of those is `B.2`. It checks what migrations
 depend on `B.2`, so it can replace that dependency with a dependency on
 `B.1_squashed_2`. It finds that `A.3` depends on `B.2`. So far so good.

 But at this point, before replacing `A.3`'s dependency on `B.2` with a
 dependency on `B.1_squashed_2`, it first checks whether `A.3` is itself
 replaced by anything. If so, it tries to update the dependencies of the
 replacing migration (that is `A.2_squashed_3`) and doesn't bother to
 update the dependencies of `A.3` itself. But it fails to check whether,
 given the already-applied migrations, `A.2_squashed_3` will _actually_ be
 allowed to replace `A.2` and `A.3` -- it just assumes the replacement will
 occur. And in the situation where the replacement doesn't occur (because
 `A.2` is applied and `A.3` is not), the dependency of `A.3` on `B.2` is
 never updated to account for the replacement of `B.2` with
 `B.1_squashed_2`, and thus there is a dependency error.

 I believe this fix should be backported to the 1.8.x branch, since it is a
 crashing bug.

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

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

Re: [Django] #24893: Django migrations don't add unique constraint for field that is changed from primary_key to unique

[Django]

#24893: Django migrations don't add unique constraint for field that is changed
from primary_key to unique
-+-
 Reporter:  jbzdak   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * status:  new => assigned
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


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

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

[Django] #24894: Add CURRENT_TIMESTAMP function to contrib.postgres

[Django]

#24894: Add CURRENT_TIMESTAMP function to contrib.postgres
--+
 Reporter:  adamchainz|  Owner:  adamchainz
 Type:  New feature   | Status:  new
Component:  contrib.postgres  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 #24866 implements a Now() function for the ORM. For postgres, it uses
 STATEMENT_TIMESTAMP(), in order to be cross-compatible with the other
 database backends, rather than CURRENT_TIMESTAMP - this is because
 CURRENT_TIMESTAMP is the same across the transaction. Adding a
 TransactionNow function to django.contrib.postgres would make this
 (default) behaviour discoverable and easily usable with Django.

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

Re: [Django] #24892: Django migrations don't escape uppercase table name in "" when using postgres backend when changing Integer field to Auto field

[Django]

#24892: Django migrations don't escape uppercase table name in "" when using
postgres backend when changing Integer  field to Auto field
-+-
 Reporter:  jbzdak   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Release blocker  |   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):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4730 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/064.a308d87b81955addb6b4f35975a03c57%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24892: Django migrations don't escape uppercase table name in "" when using postgres backend when changing Integer field to Auto field

[Django]

#24892: Django migrations don't escape uppercase table name in "" when using
postgres backend when changing Integer  field to Auto field
-+-
 Reporter:  jbzdak   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * status:  new => assigned
 * ui_ux:  1 => 0
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #24893: Django migrations don't add unique constraint for field that is changed from primary_key to unique

[Django]

#24893: Django migrations don't add unique constraint for field that is changed
from primary_key to unique
+--
 Reporter:  jbzdak  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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 jbzdak):

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


Old description:

> This is related to #24892 and uses the same code (I have attached sample
> project there)
>
> Copy-pasted description of problem:
>
> > To cut long story short: in a small application I had models using
> domain level primary keys, that were strings, I wanted to introduce
> synthetic primary keys.
> >
> > Here are models before migration (I have updated `int_pk` to be
> unique).
> >
> > {{{
> > class Foo(models.Model):
> >
> >   string_pk = models.CharField(
> > max_length=10,
> > primary_key= True
> >   )
> >
> >   int_pk = models.IntegerField(
> > null=True
> >   )
> >
> >   class Meta:
> >
> > db_table = "FOO"
> >
> > }}}
> >
> > Models after migration:
> >
> > {{{
> > class Foo(models.Model):
> >
> >   string_pk = models.CharField(
> > max_length=10,
> > unique = True
> >   )
> >
> >   int_pk = models.AutoField(
> > primary_key=True
> >   )
> >
> >   class Meta:
> >
> > db_table = "FOO"
> > }}}
> >
> > Generated migration:
> >
> > {{{
> >
> > class Migration(migrations.Migration):
> >
> > dependencies = [
> > ('testapp', '0002_foo_int_pk'),
> > ]
> >
> > operations = [
> > migrations.AlterField(
> > model_name='foo',
> > name='int_pk',
> > field=models.AutoField(primary_key=True, serialize=False),
> > ),
> > migrations.AlterField(
> > model_name='foo',
> > name='string_pk',
> > field=models.CharField(max_length=10, unique=True),
> > ),
> > ]
> > }}}
>
> I have changed field `string_pk` from `primary_key=True` to
> `unique=True`, generated migration (when I manually fixed error from
> #24892) didn't create unique constraint (previously there were a primary
> key constraint, that was dropped but there were no unique key generated).
>
> This can be (worked-around) by generating another migration with two
> `migrations.AlterField` one that sets `unique=False` and another that
> sets `unique=True`.

New description:

 This is related to #24892 and uses the same code (I have attached sample
 project there)

 Copy-pasted description of problem:

 > To cut long story short: in a small application I had models using
 domain level primary keys, that were strings, I wanted to introduce
 synthetic primary keys.
 >
 > Here are models before migration (I have updated `int_pk` to be unique).
 >
 > {{{
 > class Foo(models.Model):
 >
 >   string_pk = models.CharField(
 > max_length=10,
 > primary_key= True
 >   )
 >
 >   int_pk = models.IntegerField(
 > null=True
 >   )
 >
 >   class Meta:
 >
 > db_table = "FOO"
 >
 > }}}
 >
 > Models after migration:
 >
 > {{{
 > class Foo(models.Model):
 >
 >   string_pk = models.CharField(
 > max_length=10,
 > unique = True
 >   )
 >
 >   int_pk = models.AutoField(
 > primary_key=True
 >   )
 >
 >   class Meta:
 >
 > db_table = "FOO"
 > }}}
 >
 > Generated migration:
 >
 > {{{
 >
 > class Migration(migrations.Migration):
 >
 > dependencies = [
 > ('testapp', '0002_foo_int_pk'),
 > ]
 >
 > operations = [
 > migrations.AlterField(
 > model_name='foo',
 > name='int_pk',
 > field=models.AutoField(primary_key=True, serialize=False),
 > ),
 > migrations.AlterField(
 > model_name='foo',
 > name='string_pk',
 > field=models.CharField(max_length=10, unique=True),
 > ),
 > ]
 > }}}

 I have changed field `string_pk` from `primary_key=True` to `unique=True`,
 generated migration (when I manually fixed error from #24892) didn't
 create unique constraint (previously there were a primary key constraint,
 that was dropped but there were no unique key generated).

 This can be worked-around by generating another migration with two
 `migrations.AlterField` one that sets `unique=False` and another that sets
 `unique=True`.

--

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

-- 
You received this message because you are subscribed to the 

[Django] #24893: Django migrations don't add unique constraint for field that is changed from primary_key to unique

[Django]

#24893: Django migrations don't add unique constraint for field that is changed
from primary_key to unique
+
 Reporter:  jbzdak  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.8
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 This is related to #24892 and uses the same code (I have attached sample
 project there)

 Copy-pasted description of problem:

 > To cut long story short: in a small application I had models using
 domain level primary keys, that were strings, I wanted to introduce
 synthetic primary keys.
 >
 > Here are models before migration (I have updated `int_pk` to be unique).
 >
 > {{{
 > class Foo(models.Model):
 >
 >   string_pk = models.CharField(
 > max_length=10,
 > primary_key= True
 >   )
 >
 >   int_pk = models.IntegerField(
 > null=True
 >   )
 >
 >   class Meta:
 >
 > db_table = "FOO"
 >
 > }}}
 >
 > Models after migration:
 >
 > {{{
 > class Foo(models.Model):
 >
 >   string_pk = models.CharField(
 > max_length=10,
 > unique = True
 >   )
 >
 >   int_pk = models.AutoField(
 > primary_key=True
 >   )
 >
 >   class Meta:
 >
 > db_table = "FOO"
 > }}}
 >
 > Generated migration:
 >
 > {{{
 >
 > class Migration(migrations.Migration):
 >
 > dependencies = [
 > ('testapp', '0002_foo_int_pk'),
 > ]
 >
 > operations = [
 > migrations.AlterField(
 > model_name='foo',
 > name='int_pk',
 > field=models.AutoField(primary_key=True, serialize=False),
 > ),
 > migrations.AlterField(
 > model_name='foo',
 > name='string_pk',
 > field=models.CharField(max_length=10, unique=True),
 > ),
 > ]
 > }}}

 I have changed field `string_pk` from `primary_key=True` to `unique=True`,
 generated migration (when I manually fixed error from #24892) didn't
 create unique constraint (previously there were a primary key constraint,
 that was dropped but there were no unique key generated).

 This can be (worked-around) by generating another migration with two
 `migrations.AlterField` one that sets `unique=False` and another that sets
 `unique=True`.

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

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

Re: [Django] #24831: Pickling querysets with prefetch_related breaks

[Django]

#24831: Pickling querysets with prefetch_related breaks
-+-
 Reporter:  lsemel   |Owner:  coldmind
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


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

Re: [Django] #24892: Django migrations don't escape uppercase table name in "" when using postgres backend when changing Integer field to Auto field

[Django]

#24892: Django migrations don't escape uppercase table name in "" when using
postgres backend when changing Integer  field to Auto field
+--
 Reporter:  jbzdak  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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:  1
+--
Changes (by jbzdak):

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


Old description:

> To cut long story short: in a small application I had models using domain
> level primary keys, that were strings, I wanted to introduce synthetic
> primary keys.
>
> Here are models before migration (I have updated `int_pk` to be unique).
>
> {{{
> class Foo(models.Model):
>
>   string_pk = models.CharField(
> max_length=10,
> primary_key= True
>   )
>
>   int_pk = models.IntegerField(
> null=True
>   )
>
>   class Meta:
>
> db_table = "FOO"
>
> }}}
>
> Models after migration:
>
> {{{
> class Foo(models.Model):
>
>   string_pk = models.CharField(
> max_length=10,
> unique = True
>   )
>
>   int_pk = models.AutoField(
> primary_key=True
>   )
>
>   class Meta:
>
> db_table = "FOO"
> }}}
>
> Generated migration:
>
> {{{
>
> class Migration(migrations.Migration):
>
> dependencies = [
> ('testapp', '0002_foo_int_pk'),
> ]
>
> operations = [
> migrations.AlterField(
> model_name='foo',
> name='int_pk',
> field=models.AutoField(primary_key=True, serialize=False),
> ),
> migrations.AlterField(
> model_name='foo',
> name='string_pk',
> field=models.CharField(max_length=10, unique=True),
> ),
> ]
> }}}
>
> This migration fails with following error:
>
> {{{
> django.db.utils.ProgrammingError: relation "foo" does not exist
> }}}
>
> Generated SQL is:
>
> {{{
> ALTER TABLE "FOO" ALTER COLUMN "int_pk" TYPE integer, ALTER COLUMN
> "int_pk" SET NOT NULL;
> DROP SEQUENCE IF EXISTS FOO_int_pk_seq CASCADE;
> CREATE SEQUENCE FOO_int_pk_seq;
> ALTER TABLE FOO ALTER COLUMN int_pk SET DEFAULT
> nextval('FOO_int_pk_seq');
> SELECT setval('FOO_int_pk_seq', MAX(int_pk)) FROM FOO;
> ALTER TABLE "FOO" ADD CONSTRAINT "FOO_int_pk_5b283460a20ef820_uniq"
> UNIQUE ("int_pk");
> ALTER TABLE "FOO" DROP CONSTRAINT "FOO_pkey";
> ALTER TABLE "FOO" ADD CONSTRAINT "FOO_int_pk_5b283460a20ef820_pk" PRIMARY
> KEY ("int_pk");
> }}}
>
> Error is caused by wollowing two lines:
>
> {{{
> ALTER TABLE FOO ALTER COLUMN int_pk SET DEFAULT
> nextval('FOO_int_pk_seq');
> SELECT setval('FOO_int_pk_seq', MAX(int_pk)) FROM FOO;
> }}}
> In these lines `FOO` should be replaced by `"FOO"`

New description:

 To cut long story short: in a small application I had models using domain
 level primary keys, that were strings, I wanted to introduce synthetic
 primary keys.

 Here are models before migration (I have updated `int_pk` to be unique).

 {{{
 class Foo(models.Model):

   string_pk = models.CharField(
 max_length=10,
 primary_key= True
   )

   int_pk = models.IntegerField(
 null=True
   )

   class Meta:

 db_table = "FOO"

 }}}

 Models after migration:

 {{{
 class Foo(models.Model):

   string_pk = models.CharField(
 max_length=10,
 unique = True
   )

   int_pk = models.AutoField(
 primary_key=True
   )

   class Meta:

 db_table = "FOO"
 }}}

 Generated migration:

 {{{

 class Migration(migrations.Migration):

 dependencies = [
 ('testapp', '0002_foo_int_pk'),
 ]

 operations = [
 migrations.AlterField(
 model_name='foo',
 name='int_pk',
 field=models.AutoField(primary_key=True, serialize=False),
 ),
 migrations.AlterField(
 model_name='foo',
 name='string_pk',
 field=models.CharField(max_length=10, unique=True),
 ),
 ]
 }}}

 This migration fails with following error:

 {{{
 django.db.utils.ProgrammingError: relation "foo" does not exist
 }}}

 Generated SQL is:

 {{{
 ALTER TABLE "FOO" ALTER COLUMN "int_pk" TYPE integer, ALTER COLUMN
 "int_pk" SET NOT NULL;
 DROP SEQUENCE IF EXISTS FOO_int_pk_seq CASCADE;
 CREATE SEQUENCE FOO_int_pk_seq;
 ALTER TABLE FOO ALTER COLUMN int_pk SET DEFAULT nextval('FOO_int_pk_seq');
 SELECT setval('FOO_int_pk_seq', MAX(int_pk)) FROM FOO;
 ALTER TABLE "FOO" ADD CONSTRAINT "FOO_int_pk_5b283460a20ef820_uniq" UNIQUE
 ("int_pk");
 ALTER TABLE "FOO" DROP CONSTRAINT "FOO_pkey";
 ALTER TABLE "FOO" ADD CONSTRAINT "FOO_int_pk_5b283460a20ef820_pk" PRIMARY

Re: [Django] #24892: Django migrations don't escape uppercase table name in "" when using postgres backend when changing Integer field to Auto field

[Django]

#24892: Django migrations don't escape uppercase table name in "" when using
postgres backend when changing Integer  field to Auto field
+
 Reporter:  jbzdak  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.8
 Severity:  Normal  | Resolution:
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  1   |
+
Changes (by jbzdak):

 * Attachment "testapp.tar.gz" added.

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

[Django] #24892: Django migrations don't escape uppercase table name in "" when using postgres backend when changing Integer field to Auto field

[Django]

#24892: Django migrations don't escape uppercase table name in "" when using
postgres backend when changing Integer  field to Auto field
+
 Reporter:  jbzdak  |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.8
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  1
+
 To cut long story short: in a small application I had models using domain
 level primary keys, that were strings, I wanted to introduce synthetic
 primary keys.

 Here are models before migration (I have updated `int_pk` to be unique).

 {{{
 class Foo(models.Model):

   string_pk = models.CharField(
 max_length=10,
 primary_key= True
   )

   int_pk = models.IntegerField(
 null=True
   )

   class Meta:

 db_table = "FOO"

 }}}

 Models after migration:

 {{{
 class Foo(models.Model):

   string_pk = models.CharField(
 max_length=10,
 unique = True
   )

   int_pk = models.AutoField(
 primary_key=True
   )

   class Meta:

 db_table = "FOO"
 }}}

 Generated migration:

 {{{

 class Migration(migrations.Migration):

 dependencies = [
 ('testapp', '0002_foo_int_pk'),
 ]

 operations = [
 migrations.AlterField(
 model_name='foo',
 name='int_pk',
 field=models.AutoField(primary_key=True, serialize=False),
 ),
 migrations.AlterField(
 model_name='foo',
 name='string_pk',
 field=models.CharField(max_length=10, unique=True),
 ),
 ]
 }}}

 This migration fails with following error:

 {{{
 django.db.utils.ProgrammingError: relation "foo" does not exist
 }}}

 Generated SQL is:

 {{{
 ALTER TABLE "FOO" ALTER COLUMN "int_pk" TYPE integer, ALTER COLUMN
 "int_pk" SET NOT NULL;
 DROP SEQUENCE IF EXISTS FOO_int_pk_seq CASCADE;
 CREATE SEQUENCE FOO_int_pk_seq;
 ALTER TABLE FOO ALTER COLUMN int_pk SET DEFAULT nextval('FOO_int_pk_seq');
 SELECT setval('FOO_int_pk_seq', MAX(int_pk)) FROM FOO;
 ALTER TABLE "FOO" ADD CONSTRAINT "FOO_int_pk_5b283460a20ef820_uniq" UNIQUE
 ("int_pk");
 ALTER TABLE "FOO" DROP CONSTRAINT "FOO_pkey";
 ALTER TABLE "FOO" ADD CONSTRAINT "FOO_int_pk_5b283460a20ef820_pk" PRIMARY
 KEY ("int_pk");
 }}}

 Error is caused by wollowing two lines:

 {{{
 ALTER TABLE FOO ALTER COLUMN int_pk SET DEFAULT nextval('FOO_int_pk_seq');
 SELECT setval('FOO_int_pk_seq', MAX(int_pk)) FROM FOO;
 }}}
 In these lines `FOO` should be replaced by `"FOO"`

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

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

Re: [Django] #24891: Warn if referencing a template by the same name as one in an installed app with higher precedence

[Django]

#24891: Warn if referencing a template by the same name as one in an installed 
app
with higher precedence
-+--
 Reporter:  giuliettamasina  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by giuliettamasina):

 Replying to [comment:2 prestontimmons]:
 > I understand the confusion here, but the warning behavior is a little
 ambiguous. What if multiple loaders are defined? Or what if recursive
 inheritance is used? It's valid for an application to extend a template
 from another application with the same name.
 >
 > Some better solutions may be to:
 >
 > 1) Add logging in `django.template.loader` for `template.origin.name` so
 the full template paths can be logged to the console.
 >
 > 2) Use Django debug toolbar to see which template was used.

 I guess in the case of multiple loaders the check could be per loader or
 something like that. No warning would be emitted in the case of templates
 extending each other. However, of course this entire idea would need more
 work to handle various complex template scenarios. It might turn out to
 actually be an improvement to the documentation or such. But I've seen
 over and over developers rather new to Django run into this and I think
 there could be some improvement.

 Basically, you can have a template in your app and reference it, without
 there ever being a possibility of that template being used, unless you
 have read [https://docs.djangoproject.com/en/1.8/ref/settings/#installed-
 apps a specific sentence] in the documentation or otherwise know why.
 Logging and debugging of course help to figure this out, but I think we
 could make it even easier (and time efficient) by pointing it out to begin
 with, since we can probably know the occurrence of this case from just
 known facts about the current project/settings.

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

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

Re: [Django] #24481: Allow use of sql* commands even on apps with migrations

[Django]

#24481: Allow use of sql* commands even on apps with migrations
-+-
 Reporter:  pakal|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  migrate migrations   | Triage Stage:  Accepted
  sqlall |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by andrewgodwin):

 I've started working on this here:
 https://github.com/django/django/pull/4729

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

Re: [Django] #24891: Warn if referencing a template by the same name as one in an installed app with higher precedence

[Django]

#24891: Warn if referencing a template by the same name as one in an installed 
app
with higher precedence
-+--
 Reporter:  giuliettamasina  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by prestontimmons):

 I understand the confusion here, but the warning behavior is a little
 ambiguous. What if multiple loaders are defined? Or what if recursive
 inheritance is used? It's valid for an application to extend a template
 from another application with the same name.

 Some better solutions may be to:

 1) Add logging in `django.template.loader` for `template.origin.name` so
 the full template paths can be logged to the console.

 2) Use Django debug toolbar to see which template was used.

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

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

Re: [Django] #24891: Warn if referencing a template by the same name as one in an installed app with higher precedence

[Django]

#24891: Warn if referencing a template by the same name as one in an installed 
app
with higher precedence
-+--
 Reporter:  giuliettamasina  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 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 timgraham):

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


Comment:

 I'm not sure it's feasible to implement. A template loading call would
 have to know the "current app" from where it's being called. Is there a
 clean way to get that information?

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

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

Re: [Django] #24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease debugging

[Django]

#24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease
debugging
-+-
 Reporter:  coolRR   |Owner:  yoongkang
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"076a63e672370ff1735e7942cd1ae0990bcbd263" 076a63e]:
 {{{
 #!CommitTicketReference repository=""
 revision="076a63e672370ff1735e7942cd1ae0990bcbd263"
 Fixed #24883 -- Added MigrationGraph.__repr__()
 }}}

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

Re: [Django] #24887: Remove one-arg limitation from django.db.models.aggregate

[Django]

#24887: Remove one-arg limitation from django.db.models.aggregate
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+-
 Reporter:  etianen  |Owner:
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  proxy contenttype| Triage Stage:  Accepted
  permission |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I requested better documentation on the latest
 [https://github.com/django/django/pull/4681 pull request].

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

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

Re: [Django] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+-
 Reporter:  etianen  |Owner:
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  proxy contenttype| Triage Stage:  Accepted
  permission |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cho-is):

 Any updates on this ticket?

 As I commented on Djangocon Europe in Cardiff I found this management
 command for fixing the proxy models and create their own permissions:
 [https://gist.github.com/magopian/7543724 Gist]

 Perhaps it helpful for others running on the same issue.

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

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

Re: [Django] #24159: compilemessages does not behave the same as makemessages

[Django]

#24159: compilemessages does not behave the same as makemessages
--+
 Reporter:  dracos|Owner:  dracos
 Type:  New feature   |   Status:  assigned
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by dracos):

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

[Django] #24891: Warn if referencing a template by the same name as one in an installed app with higher precedence

[Django]

#24891: Warn if referencing a template by the same name as one in an installed 
app
with higher precedence
-+
 Reporter:  giuliettamasina  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Template system  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Due to how precedence works when looking up templates, you can write an
 app that e.g. in one of its views references a template name in the same
 app, but that will never actually be used if one by the same name exists
 in another app that is listed earlier in `INSTALLED_APPS`.

 This can be quite a surprise and frustration if you are not aware of it,
 trying to debug why your template is not being used. The common solution
 is to have an additional subdirectory in the app template folder, named
 like the app itself. But you will have to find that out first, somehow.

 I'd suggest some kind of warning is emitted if an installed app is
 referencing a template name that also exists in another installed app with
 higher precedence. The warning would ideally only happen if that template
 actually exists in the app with lower precedence.

 What do you think?

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

Re: [Django] #24890: Add warning to collectstatic when static files have clashing names

[Django]

#24890: Add warning to collectstatic when static files have clashing names
-+-
 Reporter:  giuliettamasina  |Owner:
 |  giuliettamasina
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Yes, I envisioned the warning as part of collectstatic's logging output.

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

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

Re: [Django] #24890: Add warning to collectstatic when static files have clashing names

[Django]

#24890: Add warning to collectstatic when static files have clashing names
-+-
 Reporter:  giuliettamasina  |Owner:
 |  giuliettamasina
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  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 giuliettamasina):

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


Comment:

 That sounds reasonable. Would it make sense to make such check as part of
 the management command itself? I'll probably work on this during the
 DjangoCon Europe sprints, so I'm assigning this ticket to myself for now
 :)

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

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

Re: [Django] #24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease debugging

[Django]

#24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease
debugging
-+-
 Reporter:  coolRR   |Owner:  yoongkang
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24880: Clarify docs about select_for_update() error if run outside of a transaction

[Django]

#24880: Clarify docs about select_for_update() error if run outside of a
transaction
--+
 Reporter:  suligap   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 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
--+

Comment (by Tim Graham ):

 In [changeset:"52b5890f5237ad8859108de1e0757be2b3f354c4" 52b5890]:
 {{{
 #!CommitTicketReference repository=""
 revision="52b5890f5237ad8859108de1e0757be2b3f354c4"
 [1.8.x] Fixed #24880 -- Added more explicit docs on select_for_update() on
 SQLite.

 Backport of d29ed3f355b0c57e7036807f1d54f33796d8d820 from master
 }}}

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

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

Re: [Django] #24880: Clarify docs about select_for_update() error if run outside of a transaction

[Django]

#24880: Clarify docs about select_for_update() error if run outside of a
transaction
--+
 Reporter:  suligap   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 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:"d29ed3f355b0c57e7036807f1d54f33796d8d820" d29ed3f]:
 {{{
 #!CommitTicketReference repository=""
 revision="d29ed3f355b0c57e7036807f1d54f33796d8d820"
 Fixed #24880 -- Added more explicit docs on select_for_update() on SQLite.
 }}}

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

Re: [Django] #23643: Have debug page show "During handling of this exception, another exception occurred.."

[Django]

#23643: Have debug page show "During handling of this exception, another 
exception
occurred.."
-+--
 Reporter:  cool-RR  |Owner:  tricoder42
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   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 timgraham):

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


Comment:

 In 59383f1e3a8ab5a6477dbd5bb1d7c32366a9d8f8:

 Ref #23643 -- Added plain text report of exception chain.

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

Re: [Django] #24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease debugging

[Django]

#24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease
debugging
-+-
 Reporter:  coolRR   |Owner:  yoongkang
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by yoongkang):

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

Re: [Django] #24890: Add warning to collectstatic when static files have clashing names (was: Add system check for static files that will always be overwritten on collectstatic)

[Django]

#24890: Add warning to collectstatic when static files have clashing names
-+
 Reporter:  giuliettamasina  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  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 timgraham):

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


Comment:

 I'm not sure a system check is a good idea since it seems such a check
 would involve a lot of disk reading and it could be expensive to do that
 each time the dev server is restarted (currently all system checks are
 simply static code analysis). Perhaps a warning when running collecstatic
 would be a better approach?

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

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

Re: [Django] #24885: Writing your first Django app, part 1 -> def __str__(self): problem or misunderstanding of doc?

[Django]

#24885: Writing your first Django app, part 1 -> def __str__(self): problem or
misunderstanding of doc?
-+-
 Reporter:  TitanFighter |Owner:
 Type:   |  TitanFighter
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  Writing your first   |  worksforme
  Django app, part 1, tutorial,  | 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):

 Hm, I don't see an obvious problem then. Please see
 TicketClosingReasons/UseSupportChannels for more ways to get help and
 reopen this ticket if there's something we should add to the docs after
 you get it working. Thanks!

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

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

[Django] #24890: Add system check for static files that will always be overwritten on collectstatic

[Django]

#24890: Add system check for static files that will always be overwritten on
collectstatic
-+
 Reporter:  giuliettamasina  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  contrib.staticfiles  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 If you have a project with several apps, some of which have static files
 directly in their `static` folder named identically, one of them will
 always be overwritten by the other when running `collectstatic`. The
 recommendation, and what is noted in the
 [https://docs.djangoproject.com/en/1.8/howto/static-files/ documentation],
 is to namespace by keeping all static files belonging to an app in an
 additional subdirectory in the `static` folder named like the app name.
 But if you're not doing that, the result can be very confusing. I've seen
 many developers run into this and spending quite some time before figuring
 it out through the documentation or otherwise.

 I think there should be a default system check that looks for clashing
 static file names as described above, and warn if there are files that
 will overwrite each other when running `collectstatic`.

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

Re: [Django] #24889: Multi dotted path ImportError

[Django]

#24889: Multi dotted path ImportError
---+--
 Reporter:  abstractpaper  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  1.8
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  ImportError| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 Perhaps `from __future__ import absolute_import` would help, but I'm not
 sure where to add it.

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

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

Re: [Django] #24889: Multi dotted path ImportError

[Django]

#24889: Multi dotted path ImportError
---+--
 Reporter:  abstractpaper  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  1.8
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  ImportError| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by abstractpaper):

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


Comment:

 It looks like it, although naturally django apps are imported with
 `django.apps.app_name` instead of a partial `apps.app_name`, so it would
 make more sense for `import apps.app_name` to look for the app in the
 project first and then revert back to third party packages. I'm not sure
 if this is within Django's control - namespace perhaps?

 I'm closing the ticket and renaming the folder to something else other
 than `apps`.

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

Re: [Django] #24888: A charfield with options shows with short tags in stead of verbose name in a modelform

[Django]

#24888: A charfield with options shows with short tags in stead of verbose name 
in
a modelform
---+--
 Reporter:  wimfeijen  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  1.8
 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 timgraham):

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


Comment:

 Here's the HTML I get with the code your provided (using `return
 render(request, 'form.html', {'form': RoomForm()})` as the view and `{{
 form }}` in the template):
 {{{
 Furnishing:
 Furnished
 
 Unfurnished
 
 Bare
 }}}
 This seems to be the expected result. Please reopen if you can provide
 more specific steps to reproduce.

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

Re: [Django] #24889: Multi dotted path ImportError

[Django]

#24889: Multi dotted path ImportError
---+--
 Reporter:  abstractpaper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords:  ImportError| 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:

 I suspect the problem is that your "apps" module is conflicting with
 "django.apps". Django is trying to import "from
 apps.modules.companies.models import Company" relative to "django.apps".
 Not sure if Django can do anything about this.

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

Re: [Django] #24880: Clarify docs about select_for_update() error if run outside of a transaction (was: Error on all db backends if `select_for_update` is run outside of a transaction)

[Django]

#24880: Clarify docs about select_for_update() error if run outside of a
transaction
--+
 Reporter:  suligap   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  1 => 0
 * component:  Uncategorized => Documentation
 * needs_docs:  1 => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease debugging

[Django]

#24883: Implement `django.db.migrations.graph.MigrationGraph.__repr__` to ease
debugging
-+
 Reporter:  coolRR   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.8 => master
 * easy:  0 => 1
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #22904: Django returns an HTTP 200 on a HEAD request for a non-existing file in the media folder

[Django]

#22904: Django returns an HTTP 200 on a HEAD request for a non-existing file in 
the
media folder
-+-
 Reporter:  sHtev|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.7
  uploads/storage|
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  staticfiles HEAD | Triage Stage:
  request HTTP   |  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:   => needsinfo


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

Re: [Django] #24882: Add documentation for Migration.run_before

[Django]

#24882: Add documentation for Migration.run_before
--+
 Reporter:  coolRR|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Old description:



New description:

 Reference
 
https://github.com/django/django/blob/c954931abd17f8efaa6b7662ac2916dbf47d2978/django/db/migrations/migration.py#L34-L37
 Implemented in 5826dc52827254f44833acf678f429af94b4d636

--

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

Re: [Django] #24885: Writing your first Django app, part 1 -> def __str__(self): problem or misunderstanding of doc?

[Django]

#24885: Writing your first Django app, part 1 -> def __str__(self): problem or
misunderstanding of doc?
-+-
 Reporter:  TitanFighter |Owner:
 Type:   |  TitanFighter
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  Writing your first   |  worksforme
  Django app, part 1, tutorial,  | Triage Stage:
  []  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by TitanFighter):

 Yes, i did. Didn't work.

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

Re: [Django] #24885: Writing your first Django app, part 1 -> def __str__(self): problem or misunderstanding of doc?

[Django]

#24885: Writing your first Django app, part 1 -> def __str__(self): problem or
misunderstanding of doc?
-+-
 Reporter:  TitanFighter |Owner:
 Type:   |  TitanFighter
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  Writing your first   |  worksforme
  Django app, part 1, tutorial,  | 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_docs:   => 0
 * resolution:   => worksforme
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Did you "start a new Python interactive shell by running `python manage.py
 shell`"? If you use the old one, the new methods won't take effect.

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

[Django] #24889: Multi dotted path ImportError

[Django]

#24889: Multi dotted path ImportError
---+-
 Reporter:  abstractpaper  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Core (Other)   |Version:  1.8
 Severity:  Normal |   Keywords:  ImportError
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 I have a hierarchy of apps with different nesting levels:


 {{{
 ├── apps
 │   ├── accounts
 │   ├── core
 │   ├── modules
 │   │   ├── companies
 │   │   └── products
 }}}

 I'm encountering a weird behavior where importing multi dotted apps is
 raising an `ImportError` exception:


 {{{
 Traceback (most recent call last):
   File "./manage.py", line 12, in 
 execute_from_command_line(sys.argv)
   File "/home/aziz/projects/officeman/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 338, in
 execute_from_command_line
 utility.execute()
   File "/home/aziz/projects/officeman/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 312, in execute
 django.setup()
   File "/home/aziz/projects/officeman/local/lib/python2.7/site-
 packages/django/__init__.py", line 18, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/home/aziz/projects/officeman/local/lib/python2.7/site-
 packages/django/apps/registry.py", line 108, in populate
 app_config.import_models(all_models)
   File "/home/aziz/projects/officeman/local/lib/python2.7/site-
 packages/django/apps/config.py", line 198, in import_models
 self.models_module = import_module(models_module_name)
   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
 import_module
 __import__(name)
   File "/home/aziz/projects/officeman/django/apps/accounts/models.py",
 line 8, in 
 from apps.modules.companies.models import Company
 ImportError: No module named modules.companies.models
 }}}

 Running python interpreter, I'm able to import all the different packages
 at all levels:


 {{{
 >>> from apps.modules import companies
 >>> companies
 
 >>>
 >>> from apps import modules
 >>> modules
 
 >>>
 >>> import apps
 >>> apps
 
 }}}


 The only reason I'm suspecting this to be a bug is the fact that python
 can import all the packages while Django can't. All apps imported fine in
 Django before I nested a group of them under `modules`.

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

[Django] #24888: A charfield with options shows with short tags in stead of verbose name in a modelform

[Django]

#24888: A charfield with options shows with short tags in stead of verbose name 
in
a modelform
---+
 Reporter:  wimfeijen  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Suppose you have a charfield in your model which has several choices
 defined. When you create a form from this model, the form shows the short
 tags as options (which are used for database storage) in stead of the
 verbose name (get_xxx_display) which should be used by default for
 displaying, in my opinion.

 Example:


 {{{
 FURNISHING = (
 ("yes", _("Furnished")),
 ("no", _("Unfurnished")),
 ("bare", _("Bare")),
 )

 class Room(TimeStamped):
 ...
 furnishing = models.CharField(verbose_name=_("furnishing"),
 max_length=10, choices=FURNISHING, default='no')
 ...

 FIELDS = [..., 'furnishing', ...]

 class RoomForm(forms.ModelForm):
 class Meta:
 model = Room
 fields = FIELDS
 widgets = {
 'furnishing': forms.RadioSelect(),
 }

 }}}

 (A workaround is to use the verbose names as char tags in the database.
 However, this does not work in a multilingual environment.)

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

[Django] #24887: Remove one-arg limitation from django.db.models.aggregate

[Django]

#24887: Remove one-arg limitation from django.db.models.aggregate
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The resolve_expression() method of django.db.models.aggregates.Aggregate
 asserts that there is just single source expression. I don't see the
 reason for this limitation. There are aggregates (like SQLite's
 group_concat) that naturally take in multiple arguments. It seems
 group_concat works just fine with multiple source expressions if the
 assertion is removed.

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

[Django] #24886: Add process_lhs() method for Transform

[Django]

#24886: Add process_lhs() method for Transform
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The Lookup class has two methods, process_rhs() and process_lhs(). Typical
 usage is:
 {{{
 def as_sql(self, compiler, connection):
 lhs_sql, lhs_params = self.process_lhs(compiler, connection)
 rhs_sql, rhs_params = self.process_rhs(compiler, connection)
 # return the sql
 }}}

 The typical usage for transforms is:
 {{{
 def as_sql(self, compiler, connection):
 lhs_sql, lhs_params = compiler.compile(self.lhs)
 # return the sql
 }}}

 I think it could make sense to add process_lhs() to transform base class.
 This way one could write transforms using the same process_lhs() method
 that is used for Lookups, too. At least for me it is hard to remember when
 to use process_lhs() and when to use compiler.compile.

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