Re: [Django] #33459: Explain how to optimize full text search with SearchVectorField and GinIndex

2022-01-23 Thread Django 
#33459: Explain how to optimize full text search with SearchVectorField and
GinIndex
-+-
 Reporter:  Thomas Aglassinger   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  postgres | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Thomas Aglassinger):

 Replying to [comment:4 Mariusz Felisiak]:
 > Thanks for this ticket, however indexes are standard optimization
 techniques that are helpful in most cases not only for `SearchVectorField`
 and as such it's already mentioned in
 [https://docs.djangoproject.com/en/4.0/topics/db/optimization/#use-
 standard-db-optimization-techniques docs]. I don't see any particular
 reason to document this in detail for `SearchVectorField`, the current
 docs seems sufficient to me.

 The difference with full text search is that you cannot use the standard
 indexes but have to use the particular `GinIndex` or` GistIndex` only
 provided by postgres. Also there is no real point using them with the text
 fields of your model, which I had intuitively assumed. They are only
 really useful in combination with the `SearchVectorField`.

 The current documentation does not point this out despite it being rather
 simple to show with an example.

 > It's looks like a topic for a nice blog post.

 There are plenty of blogs on the topic (I linked only one), but they are
 much more elaborate and cover more ground. I believe adding a simple
 example of combining `SearchVectorField` with `GinIndex` would help quite
 a few people that try to utilize the full text search in an efficient
 manner.

-- 
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/067.18fcaa39b562c97fab4ba6a83e08873b%40djangoproject.com.

Re: [Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

2022-01-23 Thread Django 
#33457: Expanding local vars in technical 500 causes horizontal scrolling
-+-
 Reporter:  Keryn Knight |Owner:
 |  Hrushikesh Vaidya
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  technical debug 500  | Triage Stage:  Ready for
  UI |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"89d137f3be1685dfc2ce0968835c73667bffb0ba" 89d137f3]:
 {{{
 #!CommitTicketReference repository=""
 revision="89d137f3be1685dfc2ce0968835c73667bffb0ba"
 Fixed #33457 -- Fixed "Local vars" scrolling in technical 500 debug page.

 Thanks Keryn Knight for the report and the initial patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/067.8917ba01f052d237329462827248e170%40djangoproject.com.

Re: [Django] #33458: Messages framework incorrectly serializes/deserializes extra_tags when it's an empty string

2022-01-23 Thread Django 
#33458: Messages framework incorrectly serializes/deserializes extra_tags when 
it's
an empty string
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 |  McCurrach
 Type:  Bug  |   Status:  closed
Component:  contrib.messages |  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:"efb4478e484ae61c5fc23563d4e9df1f8f49df49" efb4478]:
 {{{
 #!CommitTicketReference repository=""
 revision="efb4478e484ae61c5fc23563d4e9df1f8f49df49"
 Fixed #33458 -- Fixed encoding of messages with empty string as
 extra_tags.
 }}}

-- 
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/071.2b78e4f3ebb357ac3a059a32b8351fd5%40djangoproject.com.

Re: [Django] #33457: Expanding local vars in technical 500 causes horizontal scrolling

2022-01-23 Thread Django 
#33457: Expanding local vars in technical 500 causes horizontal scrolling
-+-
 Reporter:  Keryn Knight |Owner:
 |  Hrushikesh Vaidya
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  technical debug 500  | Triage Stage:  Ready for
  UI |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

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

Re: [Django] #33458: Messages framework incorrectly serializes/deserializes extra_tags when it's an empty string

2022-01-23 Thread Django 
#33458: Messages framework incorrectly serializes/deserializes extra_tags when 
it's
an empty string
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 |  McCurrach
 Type:  Bug  |   Status:  assigned
Component:  contrib.messages |  Version:  4.0
 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
-+-
Changes (by Mariusz Felisiak):

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

Re: [Django] #29490: Subresource integrity for form assets

2022-01-23 Thread Django 
#29490: Subresource integrity for form assets
-+
 Reporter:  Meiyer   |Owner:  Claude Paroz
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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
-+
Changes (by Mariusz Felisiak):

 * owner:  nobody => Claude Paroz
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.519d0d6b229cc5d6ccf79d04523d7692%40djangoproject.com.

Re: [Django] #33459: Explain how to optimize full text search with SearchVectorField and GinIndex

2022-01-23 Thread Django 
#33459: Explain how to optimize full text search with SearchVectorField and
GinIndex
-+-
 Reporter:  Thomas Aglassinger   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  postgres | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this ticket, however indexes are standard optimization
 techniques that are helpful in most cases not only for `SearchVectorField`
 and as such it's already mentioned in
 [https://docs.djangoproject.com/en/4.0/topics/db/optimization/#use-
 standard-db-optimization-techniques docs]. I don't see any particular
 reason to document this in detail for `SearchVectorField`, the current
 docs seems sufficient to me . It's looks like a topic for a nice blog
 post.

-- 
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/067.983f732e58c0462fd81d0d22aa1c7427%40djangoproject.com.

Re: [Django] #33450: Integer primary key is wrongly casted to UUID when filtering GenericRelation on model with UUID primary key.

2022-01-23 Thread Django 
#33450: Integer primary key is wrongly casted to UUID when filtering
GenericRelation on model with UUID primary key.
-+-
 Reporter:  Santos Gallegos  |Owner:  Jeffrey
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (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
-+-

Comment (by Jeffrey):

 Upon further investigation in Santos Gallegos original post, I also found
 that in RelatedLookupMixin.get_prep_lookup it also part of the issue since
 "target_field = self.lhs.output_field.path_infos[-1].fields[-1]" points at
 TTag's primary key which is a UUID instead of TIntegration's ID. Was able
 to resolve the issue by using reverse_path_infos but unsure if this is
 correct. So the issue is not so much related to
 
https://github.com/django/django/commit/1afbc96a75bd1765a56054f57ea2d4b238af3f4d
 which does the casting but that at this point of the code it thinks it
 should get the ID value for TTag instead of TIntegration.

 I will try to see if I can resolve the issue but wanted to share what I
 found so far. Let me know what you guys 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.aec2b69362aadcec3c5d490b143e93db%40djangoproject.com.

Re: [Django] #31486: Deprecate passing unsaved objects to related filters.

2022-01-23 Thread Django 
#31486: Deprecate passing unsaved objects to related filters.
-+-
 Reporter:  Mapiarz  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by raydeal):

 PR was closed because of
 ([https://github.com/django/django/pull/12768#discussion_r412762330
 Mariusz comment on PR]) ticket #7488 - admin panel might use filtering
 with not saved model. But it is 14 years old ticket and it is worth to
 check, in current version, if admin still use that.

-- 
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.e44a44d6e3cac60cf7a27719444d1f26%40djangoproject.com.

Re: [Django] #33459: Explain how to optimize full text search with SearchVectorField and GinIndex

2022-01-23 Thread Django 
#33459: Explain how to optimize full text search with SearchVectorField and
GinIndex
-+-
 Reporter:  Thomas Aglassinger   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  postgres | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Thomas Aglassinger:

Old description:

> The current documentation section on `SearchVectorField` at
> https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#searchvectorfield
> does not explain how to use `GinIndex` or `GistIndex` to increase the
> performance of the search. It currently only describes how to add a
> `SearchVectorField`. To my understaning this somewhat does improve the
> performance on a linear scale by removing the need to parse the fields to
> search with Postgres' full text search parser. However also indexing this
> field would typically improve performance by a mangitude.
>
> I eventually managed to piece this together from an article found at
> http://logan.tw/posts/2017/12/30/full-text-search-with-django-and-
> postgresql/ but believe this fairly standard use case should be covered
> in the Django documentation already.
>
> So I propose to add a few paragraphs that show how to add a
> `SearchVectorField` to a model with a `GinIndex`, compute a search vector
> from multiple fields and then perform a ranked search on it.
>
> For the related pull request, see
> 
> I don't consider the current patch to be final, things to discuss:
> - Should the section on "SearchVectorField" be ranamed to
> "SearchVectorField and indexing"?
> - Should the section on "Performance" be included into the section on
> "SearchVectorField"? Currently it describes the problem well but I found
> the solution of pointing to the Postgres documentation unhelpful. If
> GinIndex is mention later anyway, the pointer to the postgres
> documentation could be added afterwards for further reading.
> - Is it alright to extend the `Entry` model from the previous chapter, or
> should I add a separate model like `SearchableEntry`? The first approach
> might confuse readers if they skim over the part where `Entry` gets
> redefined and think it's the same model as in other chapters.
>
> Also it might be helpful to include a "full text search how-to" for
> example describing how to efficiently search a database of news articles
> in multiple languages. While the current reference documentation explains
> search configurations well enough, the later examples (rightfully) omit
> it to keep the explanations focused. This however limits their usefulness
> for skimming and copying the examples.
>
> If you are interested, I could write such a how-to.
>
> Related pull request: https://github.com/django/django/pull/15350

New description:

 The current documentation section on `SearchVectorField` at
 
https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#searchvectorfield
 does not explain how to use `GinIndex` or `GistIndex` to increase the
 performance of the search. It currently only describes how to add a
 `SearchVectorField`. To my understaning this somewhat does improve the
 performance on a linear scale by removing the need to parse the fields to
 search with Postgres' full text search parser. However also indexing this
 field would typically improve performance by a mangitude.

 I eventually managed to piece this together from an article found at
 http://logan.tw/posts/2017/12/30/full-text-search-with-django-and-
 postgresql/ but believe this fairly standard use case should be covered in
 the Django documentation already.

 So I propose to add a few paragraphs that show how to add a
 `SearchVectorField` to a model with a `GinIndex`, compute a search vector
 from multiple fields and then perform a ranked search on it.

 For the related pull request, see
 

 I don't consider the current patch to be final, things to discuss:
 - Should the section on "SearchVectorField" be ranamed to
 "SearchVectorField and indexing"?
 - Should the section on "Performance" be included into the section on
 "SearchVectorField"? Currently it describes the problem well but I found
 the solution of pointing to the Postgres documentation unhelpful. If
 GinIndex is mention later anyway, the pointer to the postgres
 documentation could be added afterwards for fu

Re: [Django] #33459: Explain how to optimize full text search with SearchVectorField and GinIndex

2022-01-23 Thread Django 
#33459: Explain how to optimize full text search with SearchVectorField and
GinIndex
-+-
 Reporter:  Thomas Aglassinger   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  postgres | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Thomas Aglassinger:

Old description:

> The current documentation section on `SearchVectorField` at
> https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#searchvectorfield
> does not explain how to use `GinIndex` or `GistIndex` to increase the
> performance of the search. It currently only describes how to add a
> `SearchVectorField`. To my understaning this somewhat does improve the
> performance on a linear scale by removing the need to parse the fields to
> search with Postgres' full text search parser. However also indexing this
> field would typically improve performance by a mangitude.
>
> I eventually managed to piece this together from an article found at
> http://logan.tw/posts/2017/12/30/full-text-search-with-django-and-
> postgresql/ but believe this fairly standard use case should be covered
> in the Django documentation already.
>
> So I propose to add a few paragraphs that show how to add a
> `SearchVectorField` to a model with a `GinIndex`, compute a search vector
> from multiple fields and then perform a ranked search on it.
>
> For the related pull request, see
> 
> I don't consider the current patch to be final, things to discuss:
> - Should the section on "SearchVectorField" be ranamed to
> "SearchVectorField and indexing"?
> - Should the section on "Performance" be included into the section on
> "SearchVectorField"? Currently it describes the problem well but I found
> the solution of pointing to the Postgres documentation unhelpful. If
> GinIndex is mention later anyway, the pointer to the postgres
> documentation could be added afterwards for further reading.
> - Is it alright to extend the `Entry` model from the previous chapter, or
> should I add a separate model like `SearchableEntry`? The first approach
> might confuse readers if they skim over the part where `Entry` gets
> redefined and think it's the same model as in other chapters.
>
> Also it might be helpful to include a "full text search how-to" for
> example describing how to efficiently search a database of news articles
> in multiple languages. While the current reference documentation explains
> search configurations well enough, the later examples (rightfully) omit
> it to keep the explanations focused. This however limits their usefulness
> for skimming and copying the examples.
>
> If you are interested, I could write such a how-to.

New description:

 The current documentation section on `SearchVectorField` at
 
https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#searchvectorfield
 does not explain how to use `GinIndex` or `GistIndex` to increase the
 performance of the search. It currently only describes how to add a
 `SearchVectorField`. To my understaning this somewhat does improve the
 performance on a linear scale by removing the need to parse the fields to
 search with Postgres' full text search parser. However also indexing this
 field would typically improve performance by a mangitude.

 I eventually managed to piece this together from an article found at
 http://logan.tw/posts/2017/12/30/full-text-search-with-django-and-
 postgresql/ but believe this fairly standard use case should be covered in
 the Django documentation already.

 So I propose to add a few paragraphs that show how to add a
 `SearchVectorField` to a model with a `GinIndex`, compute a search vector
 from multiple fields and then perform a ranked search on it.

 For the related pull request, see
 
 I don't consider the current patch to be final, things to discuss:
 - Should the section on "SearchVectorField" be ranamed to
 "SearchVectorField and indexing"?
 - Should the section on "Performance" be included into the section on
 "SearchVectorField"? Currently it describes the problem well but I found
 the solution of pointing to the Postgres documentation unhelpful. If
 GinIndex is mention later anyway, the pointer to the postgres
 documentation could be added afterwards for further reading.
 - Is it alright to extend the `Entry` model from the pr

Re: [Django] #33459: Explain how to optimize full text search with SearchVectorField and GinIndex

2022-01-23 Thread Django 
#33459: Explain how to optimize full text search with SearchVectorField and
GinIndex
-+-
 Reporter:  Thomas Aglassinger   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  postgres | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> The current documentation section on `SearchVectorField` at
> https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#searchvectorfield
> does not explain how to use `GinIndex` or `GistIndex` to increase the
> performance of the search. It currently only describes how to add a
> `SearchVectorField`. To my understaning this somewhat does improve the
> performance on a linear scale by removing the need to parse the fields to
> search with Postgres' full text search parser. However also indexing this
> field would typically improve performance by a mangitude.
>
> I eventually managed to piece this together from an article found at
> http://logan.tw/posts/2017/12/30/full-text-search-with-django-and-
> postgresql/ but believe this fairly standard use case should be covered
> in the Django documentation already.
>
> So I propose to add a few paragraphs that show how to add a
> `SearchVectorField` to a model with a `GinIndex`, compute a search vector
> from multiple fields and then perform a ranked search on it.
>
> I don't consider the current patch to be final, things to discuss:
> - Should the section on "SearchVectorField" be ranamed to
> "SearchVectorField and indexing"?
> - Should the section on "Performance" be included into the section on
> "SearchVectorField"? Currently it describes the problem well but I found
> the solution of pointing to the Postgres documentation unhelpful. If
> GinIndex is mention later anyway, the pointer to the postgres
> documentation could be added afterwards for further reading.
> - Is it alright to extend the `Entry` model from the previous chapter, or
> should I add a separate model like `SearchableEntry`? The first approach
> might confuse readers if they skim over the part where `Entry` gets
> redefined and think it's the same model as in other chapters.
>
> Also it might be helpful to include a "full text search how-to" for
> example describing how to efficiently search a database of news articles
> in multiple languages. While the current reference documentation explains
> search configurations well enough, the later examples (rightfully) omit
> it to keep the explanations focused. This however limits their usefulness
> for skimming and copying the examples.
>
> If you are interested, I could write such a how-to.

New description:

 The current documentation section on `SearchVectorField` at
 
https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#searchvectorfield
 does not explain how to use `GinIndex` or `GistIndex` to increase the
 performance of the search. It currently only describes how to add a
 `SearchVectorField`. To my understaning this somewhat does improve the
 performance on a linear scale by removing the need to parse the fields to
 search with Postgres' full text search parser. However also indexing this
 field would typically improve performance by a mangitude.

 I eventually managed to piece this together from an article found at
 http://logan.tw/posts/2017/12/30/full-text-search-with-django-and-
 postgresql/ but believe this fairly standard use case should be covered in
 the Django documentation already.

 So I propose to add a few paragraphs that show how to add a
 `SearchVectorField` to a model with a `GinIndex`, compute a search vector
 from multiple fields and then perform a ranked search on it.

 For the related pull request, see
 
 I don't consider the current patch to be final, things to discuss:
 - Should the section on "SearchVectorField" be ranamed to
 "SearchVectorField and indexing"?
 - Should the section on "Performance" be included into the section on
 "SearchVectorField"? Currently it describes the problem well but I found
 the solution of pointing to the Postgres documentation unhelpful. If
 GinIndex is mention later anyway, the pointer to the postgres
 documentation could be added afterwards for further reading.
 - Is it alright to extend the `Entry` model from the previous chapter, or
 should I add a separate model like `SearchableEntry`? The first approach
 might confuse readers if they ski

[Django] #33459: Explain how to optimize full text search with SearchVectorField and GinIndex

2022-01-23 Thread Django 
#33459: Explain how to optimize full text search with SearchVectorField and
GinIndex
+--
   Reporter:  Thomas Aglassinger|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  4.0
   Severity:  Normal|   Keywords:  postgres
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
 The current documentation section on `SearchVectorField` at
 
https://docs.djangoproject.com/en/dev/ref/contrib/postgres/search/#searchvectorfield
 does not explain how to use `GinIndex` or `GistIndex` to increase the
 performance of the search. It currently only describes how to add a
 `SearchVectorField`. To my understaning this somewhat does improve the
 performance on a linear scale by removing the need to parse the fields to
 search with Postgres' full text search parser. However also indexing this
 field would typically improve performance by a mangitude.

 I eventually managed to piece this together from an article found at
 http://logan.tw/posts/2017/12/30/full-text-search-with-django-and-
 postgresql/ but believe this fairly standard use case should be covered in
 the Django documentation already.

 So I propose to add a few paragraphs that show how to add a
 `SearchVectorField` to a model with a `GinIndex`, compute a search vector
 from multiple fields and then perform a ranked search on it.

 I don't consider the current patch to be final, things to discuss:
 - Should the section on "SearchVectorField" be ranamed to
 "SearchVectorField and indexing"?
 - Should the section on "Performance" be included into the section on
 "SearchVectorField"? Currently it describes the problem well but I found
 the solution of pointing to the Postgres documentation unhelpful. If
 GinIndex is mention later anyway, the pointer to the postgres
 documentation could be added afterwards for further reading.
 - Is it alright to extend the `Entry` model from the previous chapter, or
 should I add a separate model like `SearchableEntry`? The first approach
 might confuse readers if they skim over the part where `Entry` gets
 redefined and think it's the same model as in other chapters.

 Also it might be helpful to include a "full text search how-to" for
 example describing how to efficiently search a database of news articles
 in multiple languages. While the current reference documentation explains
 search configurations well enough, the later examples (rightfully) omit it
 to keep the explanations focused. This however limits their usefulness for
 skimming and copying the examples.

 If you are interested, I could write such a how-to.

-- 
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/052.3a93052a3bc70de19e8c3db08c78e5e8%40djangoproject.com.

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

2022-01-23 Thread Django 
#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  raydeal
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by raydeal):

 My patch is implemented using different approach then previous. It changes
 behaviour of FK to be the same as M2M.

 I went through discussion in this and #17541 ticket and PR for them and
 analysed examples.
 This information in the ticket
 " There is a (slightly stale) patch for #17541 which makes fk fields and
 m2m fields work consistently."
 may be true 9 years ago, but now it is not consistent with M2M.

 I have also tested previous patch
 (https://github.com/django/django/pull/13784) locally.
 I couldn't find correct rules because M2M worked as always, only changed
 behaviour of FK. When object is not saved it raises ValueError, when saved
 but related value is Null returns , which is not consistent
 for me. Why?
 Base on doubt from #17541
 https://code.djangoproject.com/ticket/17541#comment:8 I asked myself: What
 is the difference between not saved object with id (pk) refrerenced from
 other object and saved object with field containing Null value referenced
 by other object, through FK both, from the relation point of view?
 There is no difference - both of them have Null value and making related
 query in both cases doesn't make sens.

 So finally I came to the conclusion that what M2M is doing is correct - in
 both cases it raises error - and it meet some of The Zen of Python rules,
 I 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.61fb75159e5a5926c248ed4ebc84bb48%40djangoproject.com.

Re: [Django] #33199: Deprecate passing positional arguments to Signer.

2022-01-23 Thread Django 
#33199: Deprecate passing positional arguments to Signer.
-+-
 Reporter:  Daniel Samuels   |Owner:  Nikita
 |  Marchant
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jacob Walls):

 I think prepending `*args` before the existing arguments is good, but if
 you can avoid tinkering with `locals()`, the better, I think.

 What about something like:

 {{{
 diff --git a/django/core/signing.py b/django/core/signing.py
 index 5ee19a9336..724a7df507 100644
 --- a/django/core/signing.py
 +++ b/django/core/signing.py
 @@ -37,10 +37,12 @@ import base64
  import datetime
  import json
  import time
 +import warnings
  import zlib

  from django.conf import settings
  from django.utils.crypto import constant_time_compare, salted_hmac
 +from django.utils.deprecation import RemovedInDjango50Warning
  from django.utils.encoding import force_bytes
  from django.utils.module_loading import import_string
  from django.utils.regex_helper import _lazy_re_compile
 @@ -145,16 +147,25 @@ def loads(s, key=None, salt='django.core.signing',
 serializer=JSONSerializer, ma


  class Signer:
 -def __init__(self, key=None, sep=':', salt=None, algorithm=None):
 +def __init__(self, *args, key=None, sep=':', salt=None,
 algorithm=None):
  self.key = key or settings.SECRET_KEY
  self.sep = sep
 +self.salt = salt or '%s.%s' % (self.__class__.__module__,
 self.__class__.__name__)
 +self.algorithm = algorithm or 'sha256'
 +if args:
 +warnings.warn(
 +'Providing positional arguments to Signer is
 deprecated.',
 +RemovedInDjango50Warning,
 +stacklevel=2,
 +)
 +for arg, attr in zip(args, ['key', 'sep', 'salt',
 'algorithm']):
 +if arg or attr == 'sep':
 +setattr(self, attr, arg)
  if _SEP_UNSAFE.match(self.sep):
  raise ValueError(
  'Unsafe Signer separator: %r (cannot be empty or consist
 of '
  'only A-z0-9-_=)' % sep,
  )
 -self.salt = salt or '%s.%s' % (self.__class__.__module__,
 self.__class__.__name__)
 -self.algorithm = algorithm or 'sha256'


 }}}

-- 
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/071.1f169094f9e275c35b2dbafb5e121d6b%40djangoproject.com.

Re: [Django] #26142: Provide a way for model formsets to disallow new object creation

2022-01-23 Thread Django 
#26142: Provide a way for model formsets to disallow new object creation
-+
 Reporter:  Tim Graham   |Owner:  Vlad
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Vlad):

 * needs_docs:  1 => 0


Comment:

 Fixed docs, where Sphinx raised warnings

-- 
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/067.5617d075e1c863aa844410835c8ac5da%40djangoproject.com.

Re: [Django] #33199: Deprecate passing positional arguments to Signer.

2022-01-23 Thread Django 
#33199: Deprecate passing positional arguments to Signer.
-+-
 Reporter:  Daniel Samuels   |Owner:  Nikita
 |  Marchant
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nikita Marchant):

 * owner:  Daniel Samuels => Nikita Marchant


Comment:

 Hi!

 It looks like Daniel
 [https://github.com/django/django/pull/14995#issuecomment-989645451 does
 not have time] to handle this ticket so i would like to have a try.

 I spent a little time thinking about the best way to do this and I see a
 few options:
 1. Write a decorator that makes the function accept positional arguments,
 sends a warning and rewrites the call to using kwargs only
 ([https://paste.awesom.eu/62le Proof of concept])
 2. Add `*args` to the signature and use a trick with `locals()` to inject
 those into the local variables ([https://paste.awesom.eu/WqQ8 Proof of
 concept], thanks to [https://github.com/t00n t00n] for the idea and code)
 3. Change the signature to `__init__(self, *args, **kwargs)`

 1 and 2 have the advantage of not changing the signature and body of the
 function too much so it will be easy to remove when the depreciation
 period ends but are using maybe too much of dark magic. 3 is the opposite.

 What do you think would be best in Django's case ? When i know what
 approach to take, i'd be happy to update
 [https://github.com/django/django/pull/14995 Daniel's 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.33705f8f73e899909d88331509df4945%40djangoproject.com.

Re: [Django] #33308: Add psycopg3 backend

2022-01-23 Thread Django 
#33308: Add psycopg3 backend
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  backend orm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Johnson):

 * cc: Adam Johnson (added)


-- 
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/067.a35d2366ae5b20b177cff6952132c8c3%40djangoproject.com.