Closes #19977: Denormalize device relationships on component models #19984
Conversation
jeremystretch
requested review from
a team and
jnovinger
and removed request for
a team
jnovinger
left a comment
jnovinger
left a comment
There was a problem hiding this comment.
One question about the migrations and one (much less important) question about saving denormalized values via .save(). Please and thank you.
| self._rack = self.device.rack | ||
|
|
||
| super().save(*args, **kwargs) | ||
|
|
There was a problem hiding this comment.
Out of curiosity, any reason to not use the signal handler approach for this as well?
There was a problem hiding this comment.
Not really. Maybe slightly cleaner, more direct?
| _site=Subquery(subquery.values('site_id')[:1]), | ||
| _location=Subquery(subquery.values('location_id')[:1]), | ||
| _rack=Subquery(subquery.values('rack_id')[:1]), | ||
| ) |
There was a problem hiding this comment.
Any concern here about how long these updates might lock up a whole table, particularly dcim_interface? I would imagine a series of batched updates would results more, but shorter locks, meaning that other operations on the tables can happen, if needed.
I'd be curious if you had a chance to run this against a DB with 1M+ interfaces.
Having said all that, I'm far from certain this is really an issue.
There was a problem hiding this comment.
During testing with ~500K interfaces, the migration took only a few seconds to run, so I'm not too concerned about it. It's a valid point, but I'm not sure how we'd meaningfully split up the query to batch it. I wanted to use subqueries to avoid handling any of the bulk data in Python.
Closes: #19977
_site,_location, and_rackForeignKeys on all device component modelshandle_device_site_change()post_savereceiver to automatically update child components when a device is modifiedbulk_create()is employed