Re: [Django] #34205: Validation of constraints with __len lookup crashes for ArrayFields.

[Django]

#34205: Validation of constraints with __len lookup crashes for ArrayFields.
-+-
 Reporter:  James Gillard|Owner:  James
 |  Gillard
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"af3cfc863095e70f752c6b1875ed5c5dbaac2c4a" af3cfc8]:
 {{{
 #!CommitTicketReference repository=""
 revision="af3cfc863095e70f752c6b1875ed5c5dbaac2c4a"
 [4.1.x] Fixed #34205 -- Fixed Meta.constraints validation crash with
 ArrayField and __len lookup.

 Regression in 88fc9e2826044110b7b22577a227f122fe9c1fb5 that began
 manifesting in Django 4.1.

 Backport of c5ed884eabf3b2b67581c55bf6c87e721f69157f from main.
 }}}

-- 
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/01070184fd567de3-5d135fc7-59c7-4598-870b-07a23c78c7f7-00%40eu-central-1.amazonses.com.

Re: [Django] #34205: Validation of constraints with __len lookup crashes for ArrayFields.

[Django]

#34205: Validation of constraints with __len lookup crashes for ArrayFields.
-+-
 Reporter:  James Gillard|Owner:  James
 |  Gillard
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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:"c5ed884eabf3b2b67581c55bf6c87e721f69157f" c5ed884]:
 {{{
 #!CommitTicketReference repository=""
 revision="c5ed884eabf3b2b67581c55bf6c87e721f69157f"
 Fixed #34205 -- Fixed Meta.constraints validation crash with ArrayField
 and __len lookup.

 Regression in 88fc9e2826044110b7b22577a227f122fe9c1fb5 that began
 manifesting in Django 4.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/01070184fd54ebe6-25ea5aea-6b75-4567-a707-59266f211bd0-00%40eu-central-1.amazonses.com.

Re: [Django] #34207: Incorrect SQL query when adding a ManyToMany related object with a "through" table prevents adding a new relationship if the new relationship is identical except for a different v

[Django]

#34207: Incorrect SQL query when adding a ManyToMany related object with a
"through" table prevents adding a new relationship if the new relationship
is identical except for a different value for "through_defaults"
-+-
 Reporter:  Credentive   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  ManyToManyField  | Triage Stage:
  through|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > Your example documentation strongly suggests otherwise

 Could you elaborate on that? From what I can read none of the examples you
 linked suggest that `add` supports this feature?

 There is effectively a section that points at the fact that
 `remove(related)` will remove all entries matching the `(from, to)` tuple
 but defined by the many-to-many

 In the example you've just provided you don't use `members.add` to add the
 second relationship to Ringo but rely on explicit `Membership` creation
 which is supported.

 To make it clear, intermediary models that don't define a strict unique
 relationship on `(from, to)` are supported. However
 `add(through_defaults)` is focused on enforcing that at least one entry of
 the `(from, to)` tuple exists and doesn't make any assumption with regards
 to the unique constraints defined on the intermediary model.

 If you want to enforce the unique existence of a tuple that is a superset
 of the the `(from, to)` relationship you should use `get_or_create`
 instead of expecting `add(through_defaults)` to figure out which of your
 unique constraints should be enforced based on your provided
 `through_defaults`.

-- 
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/01070184fd40df1d-fecd7b51-9ea7-4ce1-8e39-d97b976c8ecc-00%40eu-central-1.amazonses.com.

Re: [Django] #33091: A FieldError should be raised when trying to update MTI inherited field with F reference to child field

[Django]

#33091: A FieldError should be raised when trying to update MTI inherited field
with F reference to child field
-+-
 Reporter:  Shai Berger  |Owner:  Abhijith
 Type:   |  Ganesh
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 Shai Berger):

 Replying to [comment:8 Bhuvnesh]:
 > I think there is no direct way to get child field from opts of parent
 model in inheritance.

 That makes sense

 > For the testcase provided by shai the value of field is None at
 
[https://github.com/django/django/blob/9da2210f121085e998dc7cedb783bc4568390b92/django/db/models/sql/query.py#L1631
 this part] ,throwing different field error
 
[https://github.com/django/django/blob/9da2210f121085e998dc7cedb783bc4568390b92/django/db/models/sql/query.py#L1714
 here.] Is it the expected behaviour?

 No, that's the bug...


 > or we are supposed to get the child field and later raise field error
 {{{Joined field references are not permitted in this query.}}}

 Yes, basically. Or, putting it another way (given your input): The
 {{{update()}}} logic uses the parent model {{{opts}}}, because the fields
 to be updated are all from that model; but then it uses the parent model
 to resolve all references, and that is wrong if there are expressions
 referencing the child model. Or, more succinctly: The move to the parent
 model is too early.

-- 
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/01070184fd38436c-9130633a-ab46-4e00-a6ca-b3f26d3dc9ee-00%40eu-central-1.amazonses.com.

Re: [Django] #13883: SelectBox.js with grouping (optgroup elements)

[Django]

#13883: SelectBox.js with grouping (optgroup elements)
-+-
 Reporter:  SardarNL |Owner:  Michael
 |  McLarnon
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  admin, SelectBox,| Triage Stage:  Accepted
  optgroup, sprintdec2010|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Jacob Walls):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070184fd2d7cce-ac56e0ae-4909-4edb-ad98-fd3832332c03-00%40eu-central-1.amazonses.com.

Re: [Django] #25617: Disallow usernames that differ only in case in UserCreationForm

[Django]

#25617: Disallow usernames that differ only in case in UserCreationForm
-+-
 Reporter:  Tim Graham   |Owner:  Paul
 Type:   |  Schilling
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  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 Jacob Walls):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * needs_docs:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070184fd232806-7d9090df-4f81-49f4-bdfa-862af906a75a-00%40eu-central-1.amazonses.com.

Re: [Django] #34036: Low text contrast over light blue backgrounds in admin light theme

[Django]

#34036: Low text contrast over light blue backgrounds in admin light theme
-+-
 Reporter:  Thibaud Colas|Owner:  Nimra
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  color contrast, ux |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Jacob Walls):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070184fd1ac51a-e2240e6f-e89b-483f-9dd0-e87dae9572c0-00%40eu-central-1.amazonses.com.

Re: [Django] #12075: Add wsgiorg.routing args support

[Django]

#12075: Add wsgiorg.routing args support
-+-
 Reporter:  Gustavo Narea|Owner:  Anvesh
 |  Mishra
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  WSGI,| Triage Stage:  Accepted
  wsgiorg.routing_args   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * 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/01070184fd16c9fd-6a90401e-4674-43a2-b1a4-e31fe7ea1ceb-00%40eu-central-1.amazonses.com.

Re: [Django] #34205: Validation of constraints with __len lookup crashes for ArrayFields.

[Django]

#34205: Validation of constraints with __len lookup crashes for ArrayFields.
-+-
 Reporter:  James Gillard|Owner:  James
 |  Gillard
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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/01070184fcf6f79e-6c9d89b3-e267-4877-83d3-b56bd11f61b7-00%40eu-central-1.amazonses.com.

Re: [Django] #34205: Validation of constraints with __len lookup crashes for ArrayFields.

[Django]

#34205: Validation of constraints with __len lookup crashes for ArrayFields.
-+-
 Reporter:  James Gillard|Owner:  James
 |  Gillard
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 James Gillard):

 * has_patch:  0 => 1


Comment:

 Thanks for the quick feedback and suggested change, that was very helpful
 for a someone who's new here :)

 I've submitted a ​[https://github.com/django/django/pull/16376 pull
 request] for this.

-- 
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/01070184fcd5388a-0015fd54-2b32-4587-ac83-d190de402aeb-00%40eu-central-1.amazonses.com.

Re: [Django] #34205: Validation of constraints with __len lookup crashes for ArrayFields.

[Django]

#34205: Validation of constraints with __len lookup crashes for ArrayFields.
-+-
 Reporter:  James Gillard|Owner:  James
 |  Gillard
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by James Gillard):

 * owner:  nobody => James Gillard
 * 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/01070184fcacd92a-1c1cd32f-f938-4b5e-8aae-7ef636fdf989-00%40eu-central-1.amazonses.com.

Re: [Django] #34207: Incorrect SQL query when adding a ManyToMany related object with a "through" table prevents adding a new relationship if the new relationship is identical except for a different v

[Django]

#34207: Incorrect SQL query when adding a ManyToMany related object with a
"through" table prevents adding a new relationship if the new relationship
is identical except for a different value for "through_defaults"
-+-
 Reporter:  Credentive   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  ManyToManyField  | Triage Stage:
  through|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Credentive):

 Your example documentation strongly suggests otherwise (while cautioning
 about "remove"), see here:
 https://docs.djangoproject.com/en/4.1/topics/db/models/#extra-fields-on-
 many-to-many-relationships

 {{{
 >>> ringo = Person.objects.create(name="Ringo Starr")
 >>> paul = Person.objects.create(name="Paul McCartney")
 >>> beatles = Group.objects.create(name="The Beatles")
 >>> m1 = Membership(person=ringo, group=beatles,
 ... date_joined=date(1962, 8, 16),
 ... invite_reason="Needed a new drummer.")
 >>> m1.save()
 >>> beatles.members.all()
 ]>
 >>> ringo.group_set.all()
 ]>
 >>> m2 = Membership.objects.create(person=paul, group=beatles,
 ... date_joined=date(1960, 8, 1),
 ... invite_reason="Wanted to form a band.")
 >>> beatles.members.all()
 , ]>
 >>> Membership.objects.create(person=ringo, group=beatles,
 ... date_joined=date(1968, 9, 4),
 ... invite_reason="You've been gone for a month and we miss you.")
 >>> beatles.members.all()
 , , ]>
 >>> # This deletes both of the intermediate model instances for Ringo
 Starr
 >>> beatles.members.remove(ringo)
 >>> beatles.members.all()
 ]>
 }}}

-- 
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/01070184fc752303-dc76f8a9-c1c9-4bd7-ac10-5232e7e6e739-00%40eu-central-1.amazonses.com.

Re: [Django] #34207: Incorrect SQL query when adding a ManyToMany related object with a "through" table prevents adding a new relationship if the new relationship is identical except for a different v

[Django]

#34207: Incorrect SQL query when adding a ManyToMany related object with a
"through" table prevents adding a new relationship if the new relationship
is identical except for a different value for "through_defaults"
-+-
 Reporter:  Credentive   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  ManyToManyField  | Triage Stage:
  through|  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:  new => closed
 * resolution:   => duplicate


Comment:

 `through_defaults` are values that are used to create a missing
 relationship between two entities that related to each other through a
 many-to-many relationship.

 If the relationship already exists between the origin and the destination,
 like it's the case when you do `statement.section.add(sect,
 through_defaults={"sl_version":new_version})`, then they are ignored as
 expected as `ManyToManyField` only supports a single related value between
 two entities.

 This is reflected in other APIs such as `statement.section.remove` which
 doesn't specify through values.

 In other words, while `ManyToManyField` supports relationship annotations
 these annotations cannot uniquely define the relationship between the
 related objects; `ManyToManyField` doesn't support multi-dimensional
 relationships.

 Duplicate of #33209

-- 
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/01070184fc7121a2-04401540-2508-4ac7-a802-dd8ded6bb266-00%40eu-central-1.amazonses.com.

[Django] #34207: Incorrect SQL query when adding a ManyToMany related object with a "through" table prevents adding a new relationship if the new relationship is identical except for a different value

[Django]

#34207: Incorrect SQL query when adding a ManyToMany related object with a
"through" table prevents adding a new relationship if the new relationship
is identical except for a different value for "through_defaults"
-+-
   Reporter: |  Owner:  nobody
  Credentive |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|   Keywords:  ManyToManyField
   Severity:  Normal |  through
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I cannot add a related element to an object that is related via a
 ManyToMany relationship with a through field. I believe I have traced the
 error to a bug in the SQL query generated.

 Some Code extracts to set the stage:

 models.py:

 {{{
 class Version(models.Model):
 uuid = models.UUIDField(primary_key=True, unique=True, editable=False,
 default=uuid.uuid4, )
 <...>

 class Section(models.Model):
 uuid = models.UUIDField(primary_key=True, unique=True, editable=False,
 default=uuid.uuid4, )
 <...>


 class Statement(models.Model):
 uuid = models.UUIDField(primary_key=True, unique=True, editable=False,
 default=uuid.uuid4, )
 <...>
 section = models.ManyToManyField(
 Section, through="StatementLocation", symmetrical=False,
 related_name="statements_in_section"
 )


 class StatementLocation(models.Model):
 section = models.ForeignKey(Section, on_delete=models.CASCADE)
 statement = models.ForeignKey(Statement, on_delete=models.CASCADE)
 sl_version = models.ForeignKey(Version, on_delete=models.CASCADE)

 class Meta:
 constraints = [
 models.UniqueConstraint(
 fields=["section", "statement", "sl_version"],
 name="unique_statement_location_per_version"
 ),
 models.UniqueConstraint(fields=["statement", "sl_version"],
 name="statement_appears_once_per_version"),
 ]
 }}}

 The idea behind the model is that we are representing a document that has
 statements in sections. Statements can be moved around in different
 versions, so the relationship between a statement and a section, called
 "statement location", must be tied to a version.

 I have a function under the Version model called "copy". The "copy"
 function produces a copy of the version and recreates the existing
 relationships.

 models.Version (extract):

 {{{
 def copy(self, name: str, public: bool) -> "Version":
 # Make a copy of a published version and return a reference to the
 copy
 # Create the new version object in the Database
 new_version = Version(
 name=name,
 state="DRAFT",
 public=public,
 obsoletes=self,
 authority=self.authority,
 )
 new_version.save()

 return new_version
 <...>

 for statement in self.version_data.statements:
 <...>
 sect = statement.section.filter(version=self).get()
 statement.section.add(sect, through_defaults={"sl_version":
 new_version})
 <...>
 }}}

 When executing the function,  I noticed that the new "StatementLocation"
 objects were not being created. For example:


 {{{
 >>> Version.objects.all()
 ]>
 >>> version = Version.objects.get()
 >>> StatementLocation.objects.count()
 89
 >>> StatementLocation.objects.filter(sl_version=version).count()
 89
 >>> new_verson = version.copy(name="2.3", public=True)
 >>> new_verson
 
 >>> StatementLocation.objects.count()
 89
 >>> StatementLocation.objects.filter(sl_version=new_verson).count()
 0
 >>>
 }}}

 If I try a simplified version, with SQL query logging enabled, I get the
 following:


 {{{
 # Create New Version
 >>> new_version = Version(name="2.3", state="DRAFT", public=True,
 obsoletes=version, authority=version.authority)

 # Save It
 >>> new_version.save()
 (0.002) SELECT "policypublisher_version"."uuid",
 "policypublisher_version"."name", "policypublisher_version"."state",
 "policypublisher_version"."public",
 "policypublisher_version"."published_date",
 "policypublisher_version"."effective_date",
 "policypublisher_version"."obsoletes_id",
 "policypublisher_version"."authority_id" FROM "policypublisher_version"
 WHERE "policypublisher_version"."uuid" =
 'bcbb218ebdc5435b9e5caf879b55cd24' LIMIT 21;
 args=('bcbb218ebdc5435b9e5caf879b55cd24',); alias=default
 (0.014) INSERT INTO "policypublisher_version" ("uuid", "name", "state",
 "public", "published_date", "effective_date", "obsoletes_id",
 "authority_id") VALUES ('bcbb218ebdc5435b9e5caf879b55cd24',