Changes between Initial Version and Version 1 of Ticket #35575, comment 6
- Timestamp:
- Jul 3, 2024, 5:19:58 PM (3 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35575, comment 6
initial v1 1 1 I feel like we should avoid the naive approach of calling `refresh_from_db(fields=generated_fields)` as that will mutate the in-memory instance and leave it in this form as well as perform an extra query per constraint. 2 2 3 What should be done IMO is for the query performed in `UniqueConstraint` to call `replace_expressions({F(gfield.name): gfield.expression.replace_expressions(....) for gfield in generated_field})` so that will turn things like3 What should be done IMO is for the query performed in `UniqueConstraint` to call `replace_expressions({F(gfield.name): gfield.expression.replace_expressions(....) for gfield in generated_field})` so that will make 4 4 5 5 … … 16 16 UniqueConstraint(names="unique_full_name", MD5("full_name")) 17 17 } 18 19 Contributor(first_name='Mark', last_name='Gensler').full_clean() 18 20 }}} 19 21 20 Then the query to full clean the unique constraint, assuming `first_name` and `last_name` are available, would be22 result in the following the query, assuming `first_name` and `last_name` are available, would be 21 23 22 24 {{{#!sql 23 25 SELECT 1 FROM contributor 24 WHERE md5(lower("first_name" || ' ' || "last_name")) = md5(lower('Mark' || ' ' || 'Gensler') 26 WHERE md5(lower("first_name" || ' ' || "last_name")) = md5(lower('Mark' || ' ' || 'Gensler')) 25 27 }}} 26 28 27 29 The more we push to the database the less likely we are to run into race conditions and serde roudtrip issues. 30 31 Note that **this isn't a problem only for UniqueConstraint** all `BaseConstraint` subclasses are affected.