Re: [Django] #30676: Add a --pdb option to the test runner

[Django]

#30676: Add a --pdb option to the test runner
-+-
 Reporter:  Andrew Godwin|Owner:  Andrew
 |  Godwin
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 OK. (We can always come back if people decide they want that.). Good 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.3562d26dfc630ff36ce6f44a8f198e2c%40djangoproject.com.

Re: [Django] #30676: Add a --pdb option to the test runner

[Django]

#30676: Add a --pdb option to the test runner
-+-
 Reporter:  Andrew Godwin|Owner:  Andrew
 |  Godwin
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andrew Godwin):

 I wasn't super happy about implying it, but I guess we could?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.1907e13e5a8b543c13769b39c26fa60f%40djangoproject.com.

Re: [Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (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 Carlton Gibson):

 * status:  closed => new
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 OK, fine, thank you for the input Simon. Let’s accept on that basis. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1f9e6e38a41f1fedb8f93b31f676ee6f%40djangoproject.com.

Re: [Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
---+--
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  2.2
 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 Thomas Hooper):

 Looks like it can be fixed with this regex change
 https://github.com/django/django/pull/11633/files

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.e319e88186b760533a233e6cc3983b98%40djangoproject.com.

Re: [Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 It should feasible to adapt `sql.Query.get_count()` to perform these
 optimizations by setting a `.values` mask when no columns are specified.

 
https://github.com/django/django/blob/05964b2198e53a8d66e34d83d9123e3051720b28/django/db/models/sql/query.py#L505-L514

 You might have to tweak the suquery pushdown logic a bit as that's what
 kicks in when `distinct` is used but it should be feasible.

 
https://github.com/django/django/blob/05964b2198e53a8d66e34d83d9123e3051720b28/django/db/models/sql/query.py#L421-L457

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2ca440dc0e25922cf9a55d9f893be9f4%40djangoproject.com.

Re: [Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
---+--
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  2.2
 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 Florian Apolloner):

 btw I confused `truncator` with `strip_tags`. So in this case the answer
 would be to rewrite the parser using `html5lib`, while `split_tags` would
 use `bleach` which in turn then uses `html5lib` as well.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a97fbbd634dfbddc9d508d5e63063d07%40djangoproject.com.

Re: [Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
---+--
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  2.2
 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 Thomas Hooper):

 Here's an example https://repl.it/@tdhooper/Django-truncate-entities-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.825ec8813c1058053a81d42e7dfd12e9%40djangoproject.com.

Re: [Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
---+--
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  2.2
 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 Florian Apolloner):

 I think now that the security release are out let's just add bleach as
 dependency on master and be done with it?

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

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

Re: [Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
---+--
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  2.2
 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 Carlton Gibson):

 Hi Thomas. Any chance of an example string (hopefully minimal) that
 creates the behaviour so we can have a look?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.26c09c09ecc674123497f0b780249f49%40djangoproject.com.

Re: [Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
---+--
 Reporter:  tdhooper   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  2.2
 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
---+--
Description changed by tdhooper:

Old description:

> I'm using Truncator to truncate wikis, and it sometimes truncates in the
> middle of  entities, resulting in 'some text '

New description:

 I'm using Truncator.chars to truncate wikis, and it sometimes truncates in
 the middle of  entities, resulting in 'some text '

--

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

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

[Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
--+
   Reporter:  tdhooper|  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Utilities   |Version:  2.2
   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   |
--+
 I'm using Truncator to truncate wikis, and it sometimes truncates in the
 middle of  entities, resulting in 'some text '

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

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

Re: [Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
 Reporter:  adamsol  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 I think the issue is that there's no way for the `distinct()` call to know
 that you're going to follow up with a `count()` — and that code to special
 case for that isn't going to worth the effort.

 If you know you only want to select a single field tell the ORM via
 
[https://docs.djangoproject.com/en/2.2/ref/models/querysets/#django.db.models.query.QuerySet.only
 `only()`]. This'll give you want you need, I think:
 `Model.objects.only('id').distinct().count()`.

 (Maybe the ORM experts can tell you more, but I suspect that be more or
 less the end of the story...)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.df697d9dbcbe6b9cd933230a35bd1f05%40djangoproject.com.

Re: [Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
 Reporter:  adamsol  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by adamsol):

 I don't think it's a bug, but I think there is a place for optimization. I
 can't see a reason why all columns are SELECTed in a subquery just to
 perform a simple count. I've attached the SQLs generated and what I would
 expect.

 So, for any model, a query like this:

 {{{Model.objects.distinct().count()}}}

 should produce an SQL like this:

 {{{SELECT COUNT(*) FROM (SELECT DISTINCT "table"."id" AS Col1 FROM
 "table") subquery;}}}

 instead of:

 {{{SELECT COUNT(*) FROM (SELECT DISTINCT "table"."id" AS Col1, ... (all
 other columns) FROM "table") subquery;}}}

 which, depending on the number of columns and size of the table, can be
 several times slower (at least on PostgreSQL).

 If you think this is not worth the effort, then OK, I won't insist.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c601f2474d248b860127577aef97a8b3%40djangoproject.com.

Re: [Django] #30676: Add a --pdb option to the test runner

[Django]

#30676: Add a --pdb option to the test runner
-+-
 Reporter:  Andrew Godwin|Owner:  Andrew
 |  Godwin
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 This is great.

 > ...this would only be possible if we were running with
 {{{--parallel=1}}}.

 As per my comment on the PR, if I pass `--pdb` could `--parallel=1` be
 implied? (I **always** want that right?)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.9ff9be55537a27e34f65a872645df164%40djangoproject.com.

Re: [Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
 Reporter:  adamsol  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Adam,

 From the description here it just looks like the expected behaviour, as
 per the
 
[https://docs.djangoproject.com/en/2.2/ref/models/querysets/#django.db.models.query.QuerySet.distinct
 various `Note` callouts in the `distinct()` documentation].

 (If you really think there's a bug here, can I ask you to narrow it down
 to something more specific? What are the exact models and ORM calls in
 play. What is the exact SQL generated? Vs What do you expect and why?
 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.9e52660ab2c610e804c6844af292037a%40djangoproject.com.

Re: [Django] #30684: Oracle Database 12.2 allows 128 byte identifiers

[Django]

#30684: Oracle Database 12.2 allows 128 byte identifiers
-+-
 Reporter:  cjbj |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  oracle database  | Triage Stage:
  identifier |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => wontfix
 * version:  2.2 => master
 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => Cleanup/optimization


Comment:

 The 30 limit has been in play literally forever (since
 ac64e91a0cadc57f4bc5cd5d66955832320ca7a1). These days, Oracle 12.2 is our
 minimum supported version, so it seems reasonable that we might be able to
 do something here. I'd provisionally accept on that basis.

 **However**: I haven't thought about the migration path.
 `truncate_name()`, with `max_name_length()` is used to generate
 identifiers in a number of places. I'm not sure how feasible it would be
 to just change that (for users with existing databases). Maybe we can do
 something clever at runtime?
 Not sure if it's feasible and/or worth the effort?

 #11898, about `quote_name()` was closed as `wontfix` because of concerns
 about a breaking changes of just this sort.

 Short of a concrete proposal I'm not sure we can move forward.

 #25428 notes that you can easily use a backend subclass to override
 `max_name_length()` in your own project. That may just be the best
 solution (if the migration path is a pain...)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.0767985f66dfc0ce655c2dec7d1d1ad0%40djangoproject.com.

[Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
   Reporter:  adamsol|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  2.2
  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  |
-+-
 I have a PostgreSQL table with 100 000 records and 15 columns.

 A simple `.count()` query results in a fast SQL (execution time in seconds
 on the left):

 {{{(0.015) SELECT COUNT(*) AS "__count" FROM "table";}}}

 When we add `.distinct()`, a subquery is created with all columns
 SELECTed:

 {{{(0.178) SELECT COUNT(*) FROM (SELECT DISTINCT "table"."id" AS Col1, ...
 (15 columns) FROM "table") subquery;}}}

 When instead of `.distinct()` we write `.distinct('id')` and add
 `.order_by('id', 'col1', 'col2')`, the subquery is additionally ORDERed:

 {{{(0.151) SELECT COUNT(*) FROM (SELECT DISTINCT ON ("table"."id")
 "table"."id" AS Col1, ... (15 columns) FROM "table" ORDER BY "table"."id"
 ASC, "table"."col1" ASC, "table"."col2" ASC) subquery;}}}

 Funny thing is that without `.distinct('id')` we can write
 `.order_by('non_existing_column')` and it works without any exception.

 After adding `.values('id')` and an empty `.order_by()`, the query is as
 fast as it can be with DISTINCT:

 {{{(0.053) SELECT COUNT(*) FROM (SELECT DISTINCT ON ("table"."id")
 "table"."id" AS Col1 FROM "table") subquery;}}}

 I think that the subquery for `count()` should never contain additional
 columns nor be ordered (and the same probably goes for other
 aggregations).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.e28f820276fe08ecb1d5fb8de4796627%40djangoproject.com.

Re: [Django] #30675: Ignore ACCEPT_LANGUAGE header only on i18n prefixed url patterns

[Django]

#30675: Ignore ACCEPT_LANGUAGE header only on i18n prefixed url patterns
-+-
 Reporter:  Janez Kranjc |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  needsinfo
 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 Carlton Gibson):

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


Comment:

 Hi Jenez,

 Thanks for the report. I kind of see the use-case here but changes here
 are non-trivial, so I think we need to flesh out the proposal, probably on
 the DevelopersMailingList, before moving forwards. (This is a delicate
 area and there's lots of expertise available there.)

 Some thoughts...

 * What's the exact use-case that's failing, and are the existing
 workarounds that we can use? (Custom middleware... Setting active language
 etc...)
 * There's a long history for the Internationalization component, and open
 tickets around `get_language_from_path()` and `..._request()` etc. Are
 these related?
 * What would the proposed change look like and what breaking changes would
 be involved?

 The need here is just to flesh out what's involved. I hope that makes
 sense.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.31a5813c7c3145418e18dd016fdd1442%40djangoproject.com.

[Django] #30684: Oracle Database 12.2 allows 128 byte identifiers

[Django]

#30684: Oracle Database 12.2 allows 128 byte identifiers
-+-
   Reporter:  cjbj   |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.2
  Uncategorized  |   Keywords:  oracle database
   Severity:  Normal |  identifier
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 
https://github.com/django/django/blob/b6c4766f53cf00bcf63cc2aa8be977c8589d083e/docs/ref/databases.txt#L889
 says that Oracle Database supports only 30 byte identifiers.  In Oracle DB
 12.2, identifiers can be 128 bytes.  It may not be wise to assume all
 12.2+ databases have set their compatibility to 12.2, but perhaps some
 handy, backwardly compatible use of the longer size can be implemented?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.994914522194cd4ea4ecb6474f002e96%40djangoproject.com.