Re: [Django] #24870: Create --update flag for makemigrations management command, mimicking South's one.

[Django]

#24870: Create --update flag for makemigrations management command, mimicking
South's one.
-+-
 Reporter:  Israel Saeta Pérez   |Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, south| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (added)
 * owner:  nobody => David Wobrock
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 Hello,

 I tried to tackle this ticket as I believe it would still be a pretty
 useful addition to `makemigrations`.
 During development, I often see developers struggle with the manual steps
 to re-generate a migration while they are still iterating on their
 approach.

 Here is the approach I've taken
 https://github.com/django/django/pull/15669
 I tried to keep the implementation rather straightforward.

 The main drawback I see is that it will add a new edge case when one
 updates a migration that has already been applied. This will create a bit
 of confusion, as it will become more tedious to undo the updated
 migration, since the reverse operations will try to undo things that
 weren't initially applied.

-- 
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/010701809b0c8157-147f23a6-ea22-460f-9810-d6fb098e1d13-00%40eu-central-1.amazonses.com.

Re: [Django] #33683: Document HttpResponseBase and allow import from django.http

[Django]

#33683: Document HttpResponseBase and allow import from django.http
--+
 Reporter:  Collin Anderson   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Collin Anderson):

 I don't really know what you mean by "protocol". Could you explain more or
 give an example of another "protocol"?

 My use case is I have a view that wraps `django.views.static.serve`, which
 returns `HttpResponseBase` according to `django-stubs`
 https://github.com/typeddjango/django-stubs/blob/master/django-
 stubs/views/static.pyi#L8.

 So my view that wraps `serve` needs also needs to be annotated as
 returning `HttpResponseBase`, so it would nice if `HttpResponseBase` was
 part of the official api, rather than being undocumented.

-- 
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/010701809a7a66be-a439700d-b123-4889-b7c8-6473ce13a4fa-00%40eu-central-1.amazonses.com.

Re: [Django] #32879: Using extra instead annotate in ORM while using select_for_update

[Django]

#32879: Using extra instead annotate in ORM while using select_for_update
-+-
 Reporter:  Zerq |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by George Tantiras):

 Replying to [comment:4 Zerq]:
 > For anyone who have the same problem:
 >
 > {{{
 > sub =
 
Subquery(Bar.objects.filter(pk=OuterRef('pk')).annotate(count=Count('*')).values('count'))
 > sub = Coalesce(sub, 0)
 > query = Foo.objects.annotate(times_used=sub)
 > }}}
 >
 > Small warning: If subquery has no values, it will return None, this is
 the reason for Coalesce.

 The above code returns incorrect results compared to the results brought
 by the following query:


 {{{
 query =
 Foo.objects.annotate(times_used=Count(F("bar"))).values("times_used")
 }}}

 The query that managed to bring the same results, according to the docs
 about [https://docs.djangoproject.com/en/dev/ref/models/expressions
 /#using-aggregates-within-a-subquery-expression using aggregates within a
 subquery expression] and
 [https://docs.djangoproject.com/en/dev/ref/models/expressions/#func-
 expressions-1 func expressions] is the following:

 {{{
 sub =
 
Subquery(Bar.objects.filter(baz=OuterRef('pk')).order_by().annotate(count=Func(F("id"),
 function="Count")).values_count("count"))
 query = Foo.objects.annotate(times_used=Coalesce(sub, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701809a27bbe5-e9d2101a-8a9f-4040-bea4-2c38f1832aa4-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: SQL generation bug in `.distinct()` when supplied fields go through multiple many-related tables

[Django]

#33682: SQL generation bug in `.distinct()` when supplied fields go through
multiple many-related tables
-+-
 Reporter:  Robert Leach |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql, distinct,   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Robert Leach):

 I believe that the note at the bottom of the distinct section of this doc:

 [https://docs.djangoproject.com/en/4.0/ref/models/querysets/#distinct]

 answers my above question, but to dissect the verbiage it tells you *what*
 to do without the *why* fully described.  It tells you that adding the
 `_id` field would be necessary to **make the expressions match** (which is
 "a" reason why to add the `id` field), but it doesn't explicitly explain
 why that makes them match, or say whether the `id` field is precisely
 required or if any field will do.

 If I'd better understood the *why* in that doc, I might have coded the
 right solution to the gotcha and not overlooked the other cases.

 My updated understanding is that it seems that the reason *a* related
 model field is necessary is because the related model "field" in the model
 definition that links to the related model isn't a "field".  It's a
 reference that gets turned into a field that by default uses the
 `meta.ordering`.  (I didn't even notice that the distinct clause had
 `compound_id` and the order by clause had `name` in that position.)  So
 I'm guessing that *any*(?) related model field in front of a (non-field)
 related model reference (whether it's at the beginning of the distinct
 list or "just before" the non-field related model reference) would solve
 the issue?  Or will *any* explicit inclusion of a non-field related model
 reference cause the problem?  **Or** perhaps even explicit inclusion of
 such a (non) field would cause the problem.

 I think these are areas in which the doc could be improved just a bit
 more.  Understanding the /why/ **better**, I think, could be helpful to
 avoid these pitfals, and also help to understand an otherwise cryptic
 error message.

-- 
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/010701809a2375a7-2fa0c291-d8a3-429a-8dbe-a18ca44cd1d4-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: SQL generation bug in `.distinct()` when supplied fields go through multiple many-related tables

[Django]

#33682: SQL generation bug in `.distinct()` when supplied fields go through
multiple many-related tables
-+-
 Reporter:  Robert Leach |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql, distinct,   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Robert Leach):

 I figured I might have been missing something.  I actually have code to
 avoid the gotcha, but apparently, I only did it for the model from which
 the query came from (i.e. the "root model"):
 {{{
 # If there are any split_rows manytomany related tables, we will
 need to prepend the ordering (and pk) fields of
 # the root model
 if len(distinct_fields) > 0:
 distinct_fields.insert(0, "pk")
 tmp_distincts =
 self.getOrderByFields(model_name=self.rootmodel.__name__)
 tmp_distincts.reverse()
 for fld_nm in tmp_distincts:
 distinct_fields.insert(0, fld_nm)

 if order_by is not None and order_by not in distinct_fields:
 distinct_fields.insert(0, order_by)
 }}}

 {{{
 def getOrderByFields(self, mdl_inst_nm=None, model_name=None):
 """
 Retrieves a model's default order by fields, given a model
 instance name.
 """
 ... brevity edit ...

 # Get a model object
 mdl = apps.get_model("DataRepo", mdl_nm)

 if "ordering" in mdl._meta.__dict__:
 return mdl._meta.__dict__["ordering"]
 return []
 }}}

 I know this ticket system is not the place for getting support, but if
 you'll indulge me... would prepending all the meta ordering fields avoid
 the gotcha if I inserted the meta ordering field(s) before any other
 fields?  (In my use case, the order is unimportant - only the distinct
 is).  I'd found that it did in the case of the "root model".

-- 
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/0107018099f50604-119e789f-ef03-417f-99bc-f67f3ddb2895-00%40eu-central-1.amazonses.com.

Re: [Django] #33681: Cache OPTIONS are not passed to the Redis client.

[Django]

#33681: Cache OPTIONS are not passed to the Redis client.
-+
 Reporter:  Ben Picolo   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Ben Picolo):

 I could probably give that a go, will see if I can take it on this weekend

-- 
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/01070180993e0907-120d95d0-ca59-43c6-9f1a-6a5dd01d393b-00%40eu-central-1.amazonses.com.

Re: [Django] #30581: Allow constraints to be used for validation (in Python)

[Django]

#30581: Allow constraints to be used for validation (in Python)
-+-
 Reporter:  Carlton Gibson   |Owner:  Gagaro
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints, | Triage Stage:  Accepted
  validation |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180991eccb8-2bb5bd57-d362-47b5-ab9b-34305ebec392-00%40eu-central-1.amazonses.com.

Re: [Django] #30581: Allow constraints to be used for validation (in Python)

[Django]

#30581: Allow constraints to be used for validation (in Python)
-+-
 Reporter:  Carlton Gibson   |Owner:  Gagaro
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints, | Triage Stage:  Accepted
  validation |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018098d4b970-af5c101a-2603-4db3-952b-3aa7b89ed9dd-00%40eu-central-1.amazonses.com.

Re: [Django] #33679: "empty" suffix gets added to last (original) admin inline form row for readonly views

[Django]

#33679: "empty" suffix gets added to last (original) admin inline form row for
readonly views
-+-
 Reporter:  Daniel Hahler|Owner:  Daniel
 |  Hahler
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"dddc8bc47d20083c63aea4a7acf1777ce197ec8d" dddc8bc]:
 {{{
 #!CommitTicketReference repository=""
 revision="dddc8bc47d20083c63aea4a7acf1777ce197ec8d"
 Fixed #33679 -- Fixed the last inline's id in admin for users without add
 permissions.
 }}}

-- 
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/010701809844ca86-3f54a6af-6f20-45a8-a5d3-3a2520221653-00%40eu-central-1.amazonses.com.