Re: [Django] #32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text search.

[Django]

#32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text
search.
--+
 Reporter:  Taneli|Owner:  Taneli
 Type:  New feature   |   Status:  assigned
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
--+
Changes (by Mariusz Felisiak):

 * type:  Uncategorized => New feature
 * version:  3.1 => master
 * component:  Uncategorized => contrib.postgres
 * stage:  Unreviewed => Accepted


Comment:

 Thanks. We should add also `TrigramWordDistance()` with the `<<->`
 operator.

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

Re: [Django] #32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text search.

[Django]

#32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text
search.
---+--
 Reporter:  Taneli |Owner:  Taneli
 Type:  Uncategorized  |   Status:  assigned
Component:  Uncategorized  |  Version:  3.1
 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 Taneli):

 * owner:  nobody => Taneli
 * 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/065.67a5e23755d088b963a9a57551028e27%40djangoproject.com.

Re: [Django] #32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text search.

[Django]

#32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text
search.
---+--
 Reporter:  Taneli |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 Taneli:

Old description:

> Use case: filter queryset by an inexact substring. For example, retrieve
> an object with the following headline ' Dogecoin is following bitcoin in
> its dramatic rise' when searching for 'dogge'.
>
> Currently it is possible to filter a queryset on the basis of trigram
> similarity between the search string and full text stored in a column.
>  {{{#!python
> Author.objects.annotate(similarity=TrigramSimilarity('name',
> test),).filter(similarity__gt=0.3)
> }}}
>
> This is a wrapper around the '''similarity''' function of the
> '''pg_trgm''' extension. While it allows comparing full strings, i.e.
> searching for 'doge'  would find 'dogs' or 'dogge' it is useless for
> fuzzy searching of substrings.
>
> {{{
> SELECT similarity('dogge', 'doge');
> -
> 0.57
>
> SELECT similarity('dogge', 'dogecoin is following bitcoin');
> 
> 0.1
> }}}
>
> '''word_similarity''' does take into account the word boundaries
>
> {{{
> SELECT word_similarity('doge', 'dogecoin is following bitcoin');
> --
> 0.5
> }}}
>
> Adding a django API to '''word_similarity''' would allow for better fuzzy
> fulltext search without a need to use either raw SQL or external tools
> like elasticsearch.

New description:

 Use case: filter queryset by an inexact substring. For example, retrieve
 an object with the following headline ''Dogecoin is following bitcoin in
 its dramatic rise'' when searching for ''dogge''.

 Currently it is possible to filter a queryset on the basis of trigram
 similarity between the search string and full text stored in a column.
  {{{#!python
 Author.objects.annotate(similarity=TrigramSimilarity('name',
 test),).filter(similarity__gt=0.3)
 }}}

 This is a wrapper around the '''similarity''' function of the
 '''pg_trgm''' extension. While it allows comparing full strings, i.e.
 searching for 'doge'  would find 'dogs' or 'dogge' it is useless for fuzzy
 searching of substrings.

 {{{
 SELECT similarity('dogge', 'doge');
 -
 0.57

 SELECT similarity('dogge', 'dogecoin is following bitcoin');
 
 0.1
 }}}

 '''word_similarity''' does take into account the word boundaries

 {{{
 SELECT word_similarity('doge', 'dogecoin is following bitcoin');
 --
 0.5
 }}}

 Adding a django API to '''word_similarity''' would allow for better fuzzy
 fulltext search without a need to use either raw SQL or external tools
 like elasticsearch.

--

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

[Django] #32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text search.

[Django]

#32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text
search.
-+
   Reporter:  Taneli |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.1
   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  |
-+
 Use case: filter queryset by an inexact substring. For example, retrieve
 an object with the following headline ' Dogecoin is following bitcoin in
 its dramatic rise' when searching for 'dogge'.

 Currently it is possible to filter a queryset on the basis of trigram
 similarity between the search string and full text stored in a column.
  {{{#!python
 Author.objects.annotate(similarity=TrigramSimilarity('name',
 test),).filter(similarity__gt=0.3)
 }}}

 This is a wrapper around the '''similarity''' function of the
 '''pg_trgm''' extension. While it allows comparing full strings, i.e.
 searching for 'doge'  would find 'dogs' or 'dogge' it is useless for fuzzy
 searching of substrings.

 {{{
 SELECT similarity('dogge', 'doge');
 -
 0.57

 SELECT similarity('dogge', 'dogecoin is following bitcoin');
 
 0.1
 }}}

 '''word_similarity''' does take into account the word boundaries

 {{{
 SELECT word_similarity('doge', 'dogecoin is following bitcoin');
 --
 0.5
 }}}

 Adding a django API to '''word_similarity''' would allow for better fuzzy
 fulltext search without a need to use either raw SQL or external tools
 like elasticsearch.

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

Re: [Django] #32491: Updating a field based on a JSONField's sub-value adds extra quotes [postgres]

[Django]

#32491: Updating a field based on a JSONField's sub-value adds extra quotes
[postgres]
-+-
 Reporter:  Baptiste Mispelon|Owner:  nobody
 Type:  Bug  |   Status:  new
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
-+-

Comment (by Nick Pope):

 Also FYI: There is an open ticket about documenting `KeyTransform()` and
 `KeyTextTransform()`: #26511

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

Re: [Django] #32477: Wrapping of admin views does not preserve view attributes

[Django]

#32477: Wrapping of admin views does not preserve view attributes
---+--
 Reporter:  Matt Pryor |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.1
 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 Nick Pope):

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


Comment:

 It is unclear what your use case is for this change as you provide no
 example of why you'd need to assign a custom attribute to a view.

 The current implementation, wrapping the function, is intended to prevent
 side effects of modifying the original function when assigning the
 `.model_admin` or `.admin_site` attributes.

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

Re: [Django] #32489: Add a generator function in runner.py to iterate over a test suite's test cases

[Django]

#32489: Add a generator function in runner.py to iterate over a test suite's 
test
cases
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  test suite,iterator,  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Chris Jerdonek):

 Also, I just noticed that the proposed `iter_test_cases()` should probably
 also sport a `reverse` keyword argument, to support e.g.
 `partition_suite_by_type()`. That way `partition_suite_by_type()` won't
 need to construct the full list before reversing it.

 (I can update my code snippet above to support passing `reverse`.)

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

Re: [Django] #32489: Add a generator function in runner.py to iterate over a test suite's test cases

[Django]

#32489: Add a generator function in runner.py to iterate over a test suite's 
test
cases
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  test suite,iterator,  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Chris Jerdonek):

 Thanks. To lower the bar for PR's, I would suggest that the first PR could
 start by adding the function and changing just one of the existing
 functions to use it (e.g. `partition_suite_by_type()`). Subsequent PR's
 could change one or more of the other functions to use 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/067.2ca889849e04368d6d8cf73ee4f3cd36%40djangoproject.com.

Re: [Django] #32491: Updating a field based on a JSONField's sub-value adds extra quotes [postgres]

[Django]

#32491: Updating a field based on a JSONField's sub-value adds extra quotes
[postgres]
-+-
 Reporter:  Baptiste Mispelon|Owner:  nobody
 Type:  Bug  |   Status:  new
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 Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 Bonjour Baptiste, always a pleasure to see you around :)

 > Initially, I thought that adding an explicit Cast (using
 update(name=Cast(F('data__name'), CharField( might solve the issue,
 but the test still fails in the same way.

 yeah that's expected since `::json::text` is pretty much the equivalent of
 `json.dumps` (e.g. see #27257 for a similar problem)

 > Adding to my confusion was the fact that this behavior doesn't appear
 when using annotate: annotate(dataname=F('data__name')) correctly yields
 django without the extra quotes.

 Right this happens because `JSONField.from_db_value` attempts a
 `json.loads` on the return value so `'"foo"' -> 'foo'`

 > I'm not sure if this is really a bug or how fixable it is (I don't see
 how Django could guess that it should use KeyTextTransform over
 KeyTransform) but silently adding extra " seems pretty bad. Having
 KeyTransform/KeyTextTransform documented could help, though I'm not sure
 if I would have discovered their existence even if they were.

 It could be done by having transforms used `for_save` have access to
 `output_field` of the left hand side of the `UPDATE`/`INSERT` (e.g a
 `CharField`) in this case and decide whether `->>` or `->` should be used
 but that would be slightly backward incompatible.

 An alternative could be to introduce an `__astext` lookup on `JSONField`
 that would translate to the usage of `KeyTextTransform`. That would make
 it explicit which SQL operator must be used and a similar approach could
 be used for `__asint` and `__asfloat` to
 
[https://github.com/django/django/blob/64a0d1ef6e7a6739148996e9584bbb61fe3dcc60/django/db/models/fields/json.py#L462-L533
 remove the lookups hacks for textual and numeric values] as right now it's
 not possible to go things like `jsonfield__name__gt="Simon"`

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

Re: [Django] #32490: Add base36 URL path converter

[Django]

#32490: Add base36 URL path converter
--+--
 Reporter:  Tilman Koschnick  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (URLs)   |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 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 Nick Pope):

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


Comment:

 I'm not sure why this needs to be defined in Django itself. The
 [https://docs.djangoproject.com/en/stable/topics/http/urls/#path-
 converters default set of path converters] doesn't even contain base64
 which would seem to be more useful than base36 to me. Creating
 [https://docs.djangoproject.com/en/3.1/topics/http/urls/#registering-
 custom-path-converters custom path converters] is trivial, so I'm not sure
 that we need to expand the default set. If you disagree, please feel free
 to raise this on the DevelopersMailingList.

-- 
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/068.1d00596aff25dbb8cd1be122aad7%40djangoproject.com.

Re: [Django] #32489: Add a generator function in runner.py to iterate over a test suite's test cases

[Django]

#32489: Add a generator function in runner.py to iterate over a test suite's 
test
cases
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  test suite,iterator,  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Nick Pope):

 * stage:  Unreviewed => Accepted


Comment:

 Sounds sensible to me. As you say, these are all just slightly different
 enough to be hard to understand.

 You proposed implementation seems fine. We might just need to be careful
 with the `groupby` in `partition_suite_by_case()`.

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

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

Re: [Django] #32487: GIN indexes on Postgres doesn't work with --nomigrations

[Django]

#32487: GIN indexes on Postgres doesn't work with --nomigrations
+--
 Reporter:  Iuri de Silvio  |Owner:  Iuri de Silvio
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  3.1
 Severity:  Normal  |   Resolution:  wontfix
 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 Simon Charette):

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


Comment:

 I also agree that this shouldn't be handled by Django by default.

-- 
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/068.6f191918ef1faf8c1300d48b3fee228c%40djangoproject.com.

Re: [Django] #32491: Updating a field based on a JSONField's sub-value adds extra quotes [postgres]

[Django]

#32491: Updating a field based on a JSONField's sub-value adds extra quotes
[postgres]
-+-
 Reporter:  Baptiste Mispelon|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Baptiste Mispelon):

 Initially, I thought that adding an explicit `Cast` (using
 `update(name=Cast(F('data__name'), CharField()))`) might solve the issue,
 but the test still fails in the same way.

 I got it to work using `KeyTextTransform` (which doesn't seem to be
 documented based on a quick `git grep`):
 `update(name=KeyTextTransform('name', 'data'))`.

 Adding to my confusion was the fact that this behavior doesn't appear when
 using `annotate`: `annotate(dataname=F('data__name'))` correctly yields
 `django` without the extra quotes.


 I'm not sure if this is really a bug or how fixable it is (I don't see how
 Django could guess that it should use `KeyTextTransform` over
 `KeyTransform`) but silently adding extra `"` seems pretty bad.
 Having `KeyTransform/KeyTextTransform` documented could help, though I'm
 not sure if I would have discovered their existence even if they were.

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

[Django] #32491: Updating a field based on a JSONField's sub-value adds extra quotes [postgres]

[Django]

#32491: Updating a field based on a JSONField's sub-value adds extra quotes
[postgres]
-+-
   Reporter:  Baptiste   |  Owner:  nobody
  Mispelon   |
   Type:  Bug| Status:  new
  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  |
-+-
 Consider the following model:
 {{{#!py
 class JSONNamedModel(models.Model):
 name = models.CharField(max_length=10, blank=True)
 data = models.JSONField()
 }}}

 The following testcase seems to pass under sqlite but fails under postgres
 (postgresql version 13.1, psycopg2 version 2.8.6). I haven't tested other
 backends:
 {{{#!py
 class ReproductionTestCase(TestCase):
 def test_issue_update(self):
 JSONNamedModel.objects.create(data={'name': 'django'})
 JSONNamedModel.objects.update(name=F('data__name'))
 self.assertQuerysetEqual(
 JSONNamedModel.objects.all(),
 ['django'],
 transform=lambda m: m.name,
 )
 }}}

 To summarize what happens in the test, if you have an instance with
 `data={'name': 'django'}` and you do `update(name=F('data__name'))`, you
 end up with an instance that has `name='"django"'` (the original name with
 extra double quotes around it).

 Interestingly, if you start with `django"`, you end up with `"django\""`
 (the original `"` is backslash-escaped and the whole thing is wrapped by
 double quotes).


 Not sure how relevant this is, but while digging into this issue I noticed
 that the test failure changed somewhat recently (bisected down to commit
 8b040e3cbbb2e81420e777afc3ca48a1c8f4dd5a).
 Before that commit, the error was `django.core.exceptions.FieldError:
 Joined field references are not permitted in this query`

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

Re: [Django] #19727: form.is_valid() always returns false

[Django]

#19727: form.is_valid() always returns false
-+-
 Reporter:  Raul s   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Accepted
  django,form,model,formmodel|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Uncategorized => Forms


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

Re: [Django] #22088: XML deserializer strips leading whitespace on loaddata

[Django]

#22088: XML deserializer strips leading whitespace on loaddata
--+
 Reporter:  Joseph-django@…   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:  xml deserialization   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Jacob Walls):

 * owner:  Martin Matusiak => (none)
 * status:  assigned => new


-- 
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/087.075a48cfbcc7c8d198efaa62429df0b3%40djangoproject.com.

Re: [Django] #22439: LiveServerTestCase handles error messages inconsistently

[Django]

#22439: LiveServerTestCase handles error messages inconsistently
--+
 Reporter:  Jeremy Bowman |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Jacob Walls):

 * owner:  Jeremy Bowman => (none)
 * status:  assigned => new


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

Re: [Django] #21540: TestCase with multiple assertRaises fails with TransactionManagementError

[Django]

#21540: TestCase with multiple assertRaises fails with 
TransactionManagementError
-+-
 Reporter:  Kevin Christopher|Owner:  (none)
  Henry  |
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.6
 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 Jacob Walls):

 * owner:  Shai Berger => (none)
 * status:  assigned => new


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

Re: [Django] #32487: GIN indexes on Postgres doesn't work with --nomigrations

[Django]

#32487: GIN indexes on Postgres doesn't work with --nomigrations
+--
 Reporter:  Iuri de Silvio  |Owner:  Iuri de Silvio
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  3.1
 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 Iuri de Silvio):

 I fixed my issue creating the extension on `pre_migrate` signal. I think
 it is a reasonable solution to decouple extension setup and index
 creation.

 I tried some solutions with Django internals but they're not good. Signal
 works for me and after some investigation I don't think it should be
 handled by 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a1821a1870792d7a9b6ebc2ec888904a%40djangoproject.com.

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

[Django]

#32263: squashmigrations produces incorrect result with a RenameModel on a
ForeignKey target.
--+
 Reporter:  InvalidInterrupt  |Owner:  (none)
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  3.1
 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 Simon Charette):

 Feels like it's the same class of issue as #32256 but for `RenameModel`
 instead of `RenameField` (7c18b22e2fa70aa8dcfadb33beb17933abdf7ee4)

 
https://github.com/django/django/blob/64a0d1ef6e7a6739148996e9584bbb61fe3dcc60/django/db/migrations/operations/models.py#L425-L430

-- 
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/074.cddc3efdea63e2e3eaf227e90875f73a%40djangoproject.com.

Re: [Django] #32490: Add base36 URL path converter

[Django]

#32490: Add base36 URL path converter
--+--
 Reporter:  Tilman Koschnick  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (URLs)   |  Version:  master
 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
--+--

Comment (by Tilman Koschnick):

 [https://github.com/django/django/pull/14060 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/068.fce2cba328cff5c7a0c43f427bcefbbe%40djangoproject.com.

[Django] #32490: Add base36 URL path converter

[Django]

#32490: Add base36 URL path converter
+
   Reporter:  Tilman Koschnick  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Core (URLs)   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 This adds base36 to the list of default URL path converters, based on
 django.utils.http.base36_to_int. It allows shorter URLs for integer values
 that are easier to type (easier to keep one's place than in a longer
 string of only numbers).

-- 
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/053.e3ddbe838e5c580703d40a1c1a30067b%40djangoproject.com.

Re: [Django] #19727: form.is_valid() always returns false

[Django]

#19727: form.is_valid() always returns false
-+-
 Reporter:  Raul s   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  django,form,model,formmodel|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hussein Naim):

 * keywords:   => django,form,model,formmodel
 * status:  closed => new
 * type:  Uncategorized => Bug
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 try to print the variable
 ```python
 form.errors
 ```
 and its will return to you the field that is not valid

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

Re: [Django] #19727: form.is_valid() always returns false

[Django]

#19727: form.is_valid() always returns false
---+--
 Reporter:  Raul s |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 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 Hussein Naim):

 one more thing if you have an image field try to remove it and try again
 for me it worked .
 i don't  know how to solve it but i remove the image filed and the form
 sending

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

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

[Django]

#32263: squashmigrations produces incorrect result with a RenameModel on a
ForeignKey target.
--+
 Reporter:  InvalidInterrupt  |Owner:  (none)
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  3.1
 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 gasparb16):

 * owner:  gasparb16 => (none)


Comment:

 I have played with this for a while but I am not sure if this can be
 solved without a larger scale code change.

-- 
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/074.c7d0cc8bc5a4b94e9f57e8ec045707c3%40djangoproject.com.

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

[Django]

#32263: squashmigrations produces incorrect result with a RenameModel on a
ForeignKey target.
--+-
 Reporter:  InvalidInterrupt  |Owner:  gasparb16
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  3.1
 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 gasparb16):

 * owner:  nobody => gasparb16
 * 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/074.f2a6eb1709dc0ab8f4e9b57928b59e64%40djangoproject.com.