Re: [Django] #18468: Add the ability to define comments in table / columns

[Django]

#18468: Add the ability to define comments in table / columns
-+-
 Reporter:  Marc Rechté  |Owner:
 |  KimSoungRyoul
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => assigned
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * owner:  nobody => KimSoungRyoul
 * needs_docs:  0 => 1
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/12605 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/065.9d9847e33d3e284f3b03f90cfc672ef0%40djangoproject.com.

Re: [Django] #31032: Document the minimal supported version of browsers for the admin

[Django]

#31032: Document the minimal supported version of browsers for the admin
-+-
 Reporter:  Claude Paroz |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"f982f0bdb8317e75af416595c616943d5025da1e" f982f0bd]:
 {{{
 #!CommitTicketReference repository=""
 revision="f982f0bdb8317e75af416595c616943d5025da1e"
 Refs #31032 -- Removed unsupported browsers workarounds and comments in
 admin's JavaScript.

 Since 8b30360322d4de6687e17ab267a856db4e3c78a6, the admin documentation
 is explicit that only modern evergreen browsers are supported. This
 allows removing several long standing workarounds for IE and Opera older
 versions.

 Since 2013, Opera is based on the Chromium blink engine.
 }}}

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

Re: [Django] #31395: Make TestCase.setUpTestData enforce in-memory data isolation.

[Django]

#31395: Make TestCase.setUpTestData enforce in-memory data isolation.
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 |  Charette
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Simon Charette
 * status:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/12608 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/067.8d14d4460f8ed285393cbc89436b715d%40djangoproject.com.

Re: [Django] #31395: Make TestCase.setUpTestData enforce in-memory data isolation.

[Django]

#31395: Make TestCase.setUpTestData enforce in-memory data isolation.
---+--
 Reporter:  Simon Charette |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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
---+--
Changes (by Simon Charette):

 * has_patch:  0 => 1


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

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

Re: [Django] #30961: Use proper whitespace in CREATE INDEX statements

[Django]

#30961: Use proper whitespace in CREATE INDEX statements
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 Type:   |  Ljungberg
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Thanks for the fix. The lack of whitespace is invalid SQL on Google's
 Cloud Spanner.

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

Re: [Django] #31395: Make TestCase.setUpTestData enforce in-memory data isolation.

[Django]

#31395: Make TestCase.setUpTestData enforce in-memory data isolation.
---+--
 Reporter:  Simon Charette |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (added)
 * version:  3.0 => master


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

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

[Django] #31395: Make TestCase.setUpTestData enforce in-memory data isolation.

[Django]

#31395: Make TestCase.setUpTestData enforce in-memory data isolation.
-+
   Reporter:  Simon Charette |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |Version:  3.0
   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  |
-+
 [https://groups.google.com/d/msg/django-
 developers/wOOlWBJYo2Y/FKj7fqPWAgAJ The following is copied from a two
 years old django-developers thread that received an initial warm welcome].


 Since then the [https://github.com/charettes/django-testdata third-party
 app] implementing this feature has not received much feedback but I know a
 few developers have been using it and my usage in a few projects didn't
 surface any issues.

 ---

 Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
 mean to
 speed up test fixtures initialization as compared to using `setUp()`.

 As I've come to use this feature and review changes from peers using it in
 different projects the fact that test data assigned during its execution
 couldn't be safely altered by test methods without compromising test
 isolation
 has often be the source of confusion and frustration.

 While the `setUpTestData` documentation mentions this limitation[1] and
 ways to
 work around it by using `refresh_from_db()` in `setUp()` I believe it
 defeats
 the whole purpose of the feature; avoiding unnecessary roundtrips to the
 database to speed up execution. Given `TestCase` goes through great
 lengths to
 ensure database level data isolation I believe it should do the same with
 class
 level in-memory data assigned during `setUpTestData`.

 In order to get rid of this caveat of the feature I'd like to propose an
 adjustment to ensure such in-memory test data isolation.

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

Re: [Django] #23916: makemigrations does not detect/like model name case changes

[Django]

#23916: makemigrations does not detect/like model name case changes
-+-
 Reporter:  Sven Coenye  |Owner:  Adam
 |  (Chainz) Johnson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * needs_tests:  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/065.81b0c8e919eb83b9ea8d6dc23700fec6%40djangoproject.com.

Re: [Django] #28194: Add search rank cd function and normalization for Postgres full text search

[Django]

#28194: Add search rank cd function and normalization for Postgres full text 
search
-+-
 Reporter:  Andrii Soldatenko|Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  1.11
 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 Simon Charette):

 * owner:  Andrii Soldatenko => Hannes Ljungberg
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/12597

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

Re: [Django] #31386: Add support for the PostgresSQL ts_rank_cd function

[Django]

#31386: Add support for the PostgresSQL ts_rank_cd function
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgres search  | Triage Stage:  Ready for
  ts_rank_cd |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


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

Re: [Django] #31394: Impossible to create with an inverse one-to-one relationship

[Django]

#31394: Impossible to create with an inverse one-to-one relationship
-+-
 Reporter:  scwall   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (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
-+-
Description changed by scwall:

Old description:

> Hello, I don't know if this is a bug or if it's something wanted. If I
> create two models .
>
> **Work >>>**
>
> Application One:
>
> 
>
> {{{
> class Foo(models.Model):
>
>foo_bar = models.IntegerField()
>
>def save(self, *args, **kwargs):
> created = self._state.adding
> super(EqoLevel, self).save(*args, **kwargs)
> if created:
> self.bar_set.create()
>
> }}}
>
> 
>
> Application Two:
>
> 
>
> {{{
> class Bar(models.Model):
>
> foo = models.ForeignKey("app1.Foo",
> on_delete=CASCADE,primary_key=True)
> foo_bar_2 = models.IntegerField()
>
> }}}
>
> **Not work >>>**
>
> Application One:
>
> 
>
> {{{
> class Foo(models.Model):
>
>foo_bar = models.IntegerField()
>
>def save(self, *args, **kwargs):
> created = self._state.adding
> super(EqoLevel, self).save(*args, **kwargs)
> if created:
> self.bar_set.create()
>
> }}}
>
> 
>
> Application Two:
>
> 
>
> {{{
> class Bar(models.Model):
>
> foo = models.OneToOneField("app1.Foo", on_delete=CASCADE)
> foo_bar_2 = models.IntegerField()
>
> }}}
>
> But if I use a  I can't run a one to one creation with an inverse
> relationship  and yet during makemigrations  it says (fields.W342)
> Setting unique=True on a ForeignKey has the same effect as using a
> OneToOneField. (HINT: ForeignKey(unique=True) is usually better served by
> a OneToOneField.),
>
> Yes but without this function I can't find it. I can also use a signal
> but I find it a shame to have to create a signal for the simple creation
> of a one to one relationship that foreign key can provide.
> Thank's

New description:

 Hello, I don't know if this is a bug or if it's something wanted. If I
 create two models .

 **Work >>>**

 Application One:

 

 {{{
 class Foo(models.Model):

foo_bar = models.IntegerField()

def save(self, *args, **kwargs):
 created = self._state.adding
 super(Foo, self).save(*args, **kwargs)
 if created:
 self.bar_set.create()

 }}}

 

 Application Two:

 

 {{{
 class Bar(models.Model):

 foo = models.ForeignKey("app1.Foo",
 on_delete=CASCADE,primary_key=True)
 foo_bar_2 = models.IntegerField()

 }}}

 **Not work >>>**

 Application One:

 

 {{{
 class Foo(models.Model):

foo_bar = models.IntegerField()

def save(self, *args, **kwargs):
 created = self._state.adding
 super(EqoLevel, self).save(*args, **kwargs)
 if created:
 self.bar_set.create()

 }}}

 

 Application Two:

 

 {{{
 class Bar(models.Model):

 foo = models.OneToOneField("app1.Foo", on_delete=CASCADE)
 foo_bar_2 = models.IntegerField()

 }}}

 But if I use a  I can't run a one to one creation with an inverse
 relationship  and yet during makemigrations  it says (fields.W342) Setting
 unique=True on a ForeignKey has the same effect as using a OneToOneField.
 (HINT: ForeignKey(unique=True) is usually better served by a
 OneToOneField.),

 Yes but without this function I can't find it. I can also use a signal but
 I find it a shame to have to create a signal for the simple creation of a
 one to one relationship that foreign key can provide.
 Thank's

--

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

Re: [Django] #31394: Impossible to create with an inverse one-to-one relationship

[Django]

#31394: Impossible to create with an inverse one-to-one relationship
-+-
 Reporter:  scwall   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (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
-+-
Description changed by scwall:

Old description:

> Hello, I don't know if this is a bug or if it's something wanted. If I
> create two models .
>
> **Work >>>**
>
> Application One:
>
> 
>
> {{{
> class Foo(models.Model):
>
>foo_bar = models.IntegerField()
>
>def save(self, *args, **kwargs):
> created = self._state.adding
> super(EqoLevel, self).save(*args, **kwargs)
> if created:
> self.bar_set.create()
>
> }}}
>
> 
>
> Application Two:
>
> 
>
> {{{
> class Bar(models.Model):
>
> foo = models.ForeignKey("app1.Foo",
> on_delete=CASCADE,primary_key=True)
> foo_bar_2 = models.IntegerField()
>
> }}}
>
> **Not work >>>**
>
> Application One:
>
> 
>
> {{{
> class Foo(models.Model):
>
>foo_bar = models.IntegerField()
>
>def save(self, *args, **kwargs):
> created = self._state.adding
> super(EqoLevel, self).save(*args, **kwargs)
> if created:
> self.bar_set.create()
>
> }}}
>
> 
>
> Application Two:
>
> 
>
> {{{
> class Bar(models.Model):
>
> foo = models.OneToOneField("app1.Foo", on_delete=CASCADE)
> foo_bar_2 = models.IntegerField()
>
> }}}
>
> But if I use a  I can't run a one to one creation with an inverse
> relationship  and yet during makemigrations  it says (HINT:
> ForeignKey(unique=True) is usually better served by a OneToOneField.),
>
> Yes but without this function I can't find it. I can also use a signal
> but I find it a shame to have to create a signal for the simple creation
> of a one to one relationship that foreign key can provide.
> Thank's

New description:

 Hello, I don't know if this is a bug or if it's something wanted. If I
 create two models .

 **Work >>>**

 Application One:

 

 {{{
 class Foo(models.Model):

foo_bar = models.IntegerField()

def save(self, *args, **kwargs):
 created = self._state.adding
 super(EqoLevel, self).save(*args, **kwargs)
 if created:
 self.bar_set.create()

 }}}

 

 Application Two:

 

 {{{
 class Bar(models.Model):

 foo = models.ForeignKey("app1.Foo",
 on_delete=CASCADE,primary_key=True)
 foo_bar_2 = models.IntegerField()

 }}}

 **Not work >>>**

 Application One:

 

 {{{
 class Foo(models.Model):

foo_bar = models.IntegerField()

def save(self, *args, **kwargs):
 created = self._state.adding
 super(EqoLevel, self).save(*args, **kwargs)
 if created:
 self.bar_set.create()

 }}}

 

 Application Two:

 

 {{{
 class Bar(models.Model):

 foo = models.OneToOneField("app1.Foo", on_delete=CASCADE)
 foo_bar_2 = models.IntegerField()

 }}}

 But if I use a  I can't run a one to one creation with an inverse
 relationship  and yet during makemigrations  it says (fields.W342) Setting
 unique=True on a ForeignKey has the same effect as using a OneToOneField.
 (HINT: ForeignKey(unique=True) is usually better served by a
 OneToOneField.),

 Yes but without this function I can't find it. I can also use a signal but
 I find it a shame to have to create a signal for the simple creation of a
 one to one relationship that foreign key can provide.
 Thank's

--

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

[Django] #31394: Impossible to create with an inverse one-to-one relationship

[Django]

#31394: Impossible to create with an inverse one-to-one relationship
-+-
   Reporter:  scwall |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello, I don't know if this is a bug or if it's something wanted. If I
 create two models .

 **Work >>>**

 Application One:

 

 {{{
 class Foo(models.Model):

foo_bar = models.IntegerField()

def save(self, *args, **kwargs):
 created = self._state.adding
 super(EqoLevel, self).save(*args, **kwargs)
 if created:
 self.bar_set.create()

 }}}

 

 Application Two:

 

 {{{
 class Bar(models.Model):

 foo = models.ForeignKey("app1.Foo",
 on_delete=CASCADE,primary_key=True)
 foo_bar_2 = models.IntegerField()

 }}}

 **Not work >>>**

 Application One:

 

 {{{
 class Foo(models.Model):

foo_bar = models.IntegerField()

def save(self, *args, **kwargs):
 created = self._state.adding
 super(EqoLevel, self).save(*args, **kwargs)
 if created:
 self.bar_set.create()

 }}}

 

 Application Two:

 

 {{{
 class Bar(models.Model):

 foo = models.OneToOneField("app1.Foo", on_delete=CASCADE)
 foo_bar_2 = models.IntegerField()

 }}}

 But if I use a  I can't run a one to one creation with an inverse
 relationship  and yet during makemigrations  it says (HINT:
 ForeignKey(unique=True) is usually better served by a OneToOneField.),

 Yes but without this function I can't find it. I can also use a signal but
 I find it a shame to have to create a signal for the simple creation of a
 one to one relationship that foreign key can provide.
 Thank's

-- 
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/049.82626ade72dbb3dbb27edff73136ed3b%40djangoproject.com.

Re: [Django] #31386: Add support for the PostgresSQL ts_rank_cd function

[Django]

#31386: Add support for the PostgresSQL ts_rank_cd function
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgres search  | Triage Stage:  Ready for
  ts_rank_cd |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hannes Ljungberg):

 I don’t know how I missed that ticket. Sorry about that!

 Sure, let’s close this ticket in favor of #28194. I’ll update my PR to add
 support for the ` normalization` parameter.

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

Re: [Django] #31386: Add support for the PostgresSQL ts_rank_cd function

[Django]

#31386: Add support for the PostgresSQL ts_rank_cd function
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgres search  | Triage Stage:  Ready for
  ts_rank_cd |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I guess we could close this one as duplicate of #28194 and have
 https://github.com/django/django/pull/12597 address both.

 Is it something you're interested in doing Hannes?

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

Re: [Django] #31386: Add support for the PostgresSQL ts_rank_cd function

[Django]

#31386: Add support for the PostgresSQL ts_rank_cd function
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgres search  | Triage Stage:  Ready for
  ts_rank_cd |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Almost a duplicate of #28194. However, #28194 also suggests adding the
 `normalization` keyword parameter. Should we keep both tickets and address
 both issues separately?

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

Re: [Django] #31393: Support table SQL comments. (was: Support SQL comment with help_text -> comment)

[Django]

#31393: Support table SQL comments.
-+-
 Reporter:  KimSoungRyoul|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  COMMENT help_text| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  assigned => closed
 * resolution:   => duplicate
 * component:  Migrations => Database layer (models, ORM)


Comment:

 Duplicate of #18468.

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

[Django] #31393: Support SQL comment with help_text -> comment

[Django]

#31393: Support SQL comment  with help_text -> comment
-+-
   Reporter: |  Owner:  nobody
  KimSoungRyoul  |
   Type:  New| Status:  assigned
  feature|
  Component: |Version:  master
  Migrations |
   Severity:  Normal |   Keywords:  COMMENT help_text
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 why don't you support SQL COMMENT ?

 help_text is useful for Developer

 **BUT**

 **DBA can not understand Django Models**
 They want to see help_text with SQL not Python

 This Issue causes a loss of communication costs between Developer to DBA



 == **here is a solution**



 == AS IS


 {{{
  class AModel(models.Model):
 a_field = models.CharField(help_text="this is help text",
 max_length=32, null=False)

 class Meta:
db_table_comment =" this is comment"
 }}}


 -> python manage.py makemigrations
 -> python manage.py migrate

 Executed SQL (example Mysql)

 {{{

 create table a_model
 (
a_field varchar(32) not null COMMENT 'this is help text'
 ) comment 'this is doc string';
 }}}

-- 
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/056.17cf9457b95897bceddb316ecfe3359c%40djangoproject.com.