hi, sorry sarahboyce, charettes, ngnpope, felixxm to tag you but i really need to understand the implication of tiket #34943 on #34277. see also this link
sorry for the inconvenience
I think don’t worry.
Cc yourself to the ticket so you get updates on it’s progress. If someone starts working on this before your PR lands, there will be some conflicts to resolve between the two, but it might not get picked up that quickly. 
Thank you, sarahboyce,
I wanted to thank you for your feedback. I am optimistic about completing my PR on time. However, my main concern is understanding the purpose from the moment charettes talks about regression. Would it be possible for my work on ticket 34277 to be merged at the end by the Django team?
Sorry you need to be more specific. Where is there a discussion on regresion, can you link the comment you’re referring to?
And by “at the end”, what do you mean? At the end of what?
My recommendation would be to introduce a
unique_constraint: str | tuple[str | Expression]kwarg and deprecateunique_fields. When provided astrit would be a reference to aUniqueConstraintby.nameand when it’s atupleit would be expected to be a index expression wherestrare resolved to field names.
by “at the end”, I mean the end of my contribution on 34277
Alright still not quite sure what worries you.
In that discussion he talks about “depreciation” (because changing the purpose and name of unique_fields is a breaking change).
A “regression” would be a bug in the codebase introduced by a different code change.
Your contribution is done when it’s merged. It will get merged once it is “ready” to merge.
As you have an accepted ticket, there’s no reason to believe it can’t be merged. More a process of reviews and revisions.
1 Like
thank you for the clarification sarahboyce you are an angel.
my whole problem was the word “depreciation” which i had apparently read as “regression”. now everything is in order in my head. sorry for the confusion 
.
1 Like