Skip to content

Conversation

JaeHyuckSa
Copy link
Contributor

Trac ticket number

ticket-36580

Checklist

  • This PR targets the main branch.
  • The commit message is written in past tense, mentions the ticket number, and ends with a period.
  • I have checked the "Has patch" ticket flag in the Trac system.
  • I have added or updated relevant tests.
  • I have added or updated relevant docs, including release notes if applicable.
  • I have attached screenshots in both light and dark modes for any UI changes.

@JaeHyuckSa JaeHyuckSa force-pushed the issue-36580 branch 2 times, most recently from 9f3971a to efb8415 Compare August 30, 2025 11:18
@JaeHyuckSa JaeHyuckSa changed the title Fixed #36580 -- Fixed constraint validation with Q() referencing ForeignObject. Fixed #36580 -- Fixed constraint validation crash when condition uses a ForeignObject. Aug 30, 2025
@jacobtylerwalls
Copy link
Member

jacobtylerwalls commented Aug 30, 2025

Thanks for the speedy work here @JaeHyuckSa, but I just triaged the ticket to needsinfo, so I think we need to close this for now.

@jacobtylerwalls
Copy link
Member

My mistake, reopening! I had forgotten to change user__isnull when testing against test models copied from the docs 🤦

@jacobtylerwalls
Copy link
Member

buildbot, test on oracle.

Copy link
Member

@jacobtylerwalls jacobtylerwalls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @JaeHyuckSa. The constraint on the test model can't be created on Oracle:

django.db.utils.DatabaseError: ORA-00904: "COMPOSITE_PK_COMMENT"."USER_ID": invalid identifier

@felixxm have you seen this Oracle error before? If there's a workaround, it would be nice to avoid creating a separate test model just to skip a test on Oracle.

@felixxm
Copy link
Member

felixxm commented Sep 2, 2025

django.db.utils.DatabaseError: ORA-00904: "COMPOSITE_PK_COMMENT"."USER_ID": invalid identifier

@felixxm have you seen this Oracle error before? If there's a workaround, it would be nice to avoid creating a separate test model just to skip a test on Oracle.

It means that USER_ID column doesn't exist on this model 🤔 I can check later DDLs that we execute.

Also, I wouldn't mix this with composite PK tests but add them to the tests/foreign_object/.

@JaeHyuckSa JaeHyuckSa force-pushed the issue-36580 branch 2 times, most recently from 50af1d7 to 9776e8f Compare September 2, 2025 17:43
Copy link
Member

@jacobtylerwalls jacobtylerwalls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate the help with this one @JaeHyuckSa! I have a few comments.

@felixxm
Copy link
Member

felixxm commented Sep 2, 2025

I can check later DDLs that we execute.

The current version works for me on Oracle 🤷

@jacobtylerwalls
Copy link
Member

Thanks for checking. Might be a multi-column-only DDL issue then 😉 .

@jacobtylerwalls
Copy link
Member

Hi @JaeHyuckSa 👋

Thanks for pushing this forward. This is a release blocker for 6.0, so we need to clear it by the middle of next week. Do you anticipate having time to continue it this week? Thanks.

@JaeHyuckSa
Copy link
Contributor Author

JaeHyuckSa commented Sep 8, 2025

Hi @JaeHyuckSa 👋

Thanks for pushing this forward. This is a release blocker for 6.0, so we need to clear it by the middle of next week. Do you anticipate having time to continue it this week? Thanks.

Hi @jacobtylerwalls Jacob!
I’ve been swamped with a lot of tasks all of a sudden, so I couldn’t get to this earlier. I’m planning to address your review comments on this PR either by tomorrow at the earliest, or within the next two days at the latest. Thanks for the reminder.

@jacobtylerwalls jacobtylerwalls self-assigned this Sep 14, 2025
@JaeHyuckSa JaeHyuckSa force-pushed the issue-36580 branch 2 times, most recently from a560e34 to 64e4c91 Compare September 15, 2025 15:34
@JaeHyuckSa
Copy link
Contributor Author

@jacobtylerwalls Hi Jacob

Sorry for the delay in addressing this; I wasn’t able to keep up with the agreed timeline as a lot of work suddenly came in. I’ve applied the simpler review comments, and regarding the requested test code, would this level of coverage be appropriate? Currently, the tests are failing for another reason: as you mentioned, a performance regression is occurring because both fields are being checked, which triggers an error. I think we’ll need to resolve this by making use of field.local_related_fields.

@jacobtylerwalls
Copy link
Member

Thanks for the update. I'll pick it up from here later this afternoon.

@JaeHyuckSa
Copy link
Contributor Author

Thanks for the update. I'll pick it up from here later this afternoon.

@jacobtylerwalls Thank you for reviewing. I've applied the changes you suggested above. :)

@jacobtylerwalls
Copy link
Member

@charettes I took a stab at a simpler approach, how does it look?

Comment on lines 1380 to 1381
else:
value = getattr(self, field.attname)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we continue if the field is not concrete?

Suggested change
else:
value = getattr(self, field.attname)
elif field.concrete:
value = getattr(self, field.attname)
else:
continue

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have an idea for a test that would cover that case?

Copy link
Member

@charettes charettes Sep 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you'd have to test _get_field_expression_map directly for it as we don't have a lot of non-concrete in core.

The only two I can think about are GenericForeignKey and soon ManyToManyField after #19602 lands. The idea is that for these fields getattr(self, field.attname) could return a manager which is not suitable to be passed as the right-hand-side in a lookup.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. In that case let's add coverage via ManyToManyField on #19602. I'll leave a note.

Comment on lines +1375 to +1379
value = tuple(
getattr(self, from_field) for from_field in field.from_fields
)
if len(value) == 1:
value = value[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This highlights were still missing proper handling for non-pk composite fields.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly -- I'll open a follow-up issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried to capture this in ticket-36611, but if you meant something else, let me know! 🙏

@jacobtylerwalls jacobtylerwalls merged commit 8c621e9 into django:main Sep 16, 2025
42 of 44 checks passed
@jacobtylerwalls
Copy link
Member

Thanks @JaeHyuckSa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants