-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Checkin results in IntegrityError #90
Comments
Update history tracking sucks in general (see #68) and needs to be rewritten. This is another example of that. |
This is filling my logs. I have log rotation on, but I am definitely seeing that the dashboard takes progressively longer and longer to load over time. I'd love to rule this out as a reason. If you have any directed suggestions, I could look into this since it is affecting me and I'm feeling motivated. |
Honestly, it needs to be burned and start again. I wrote it when we got significantly less info from the ManagedInstallsReport.plist, we should be able to get everything from that now. This didn't change from 2.7.x though. |
Hmmm. I'll see if I can patch my production server to at least ignore those errors. |
As far as I can understand this, the problem was that an UpdateHistoryItem was created, and then immediately had `.save()` called. Then, on postgres, it would then later do a bulk_create on the UpdateHistoryItem model. Since the model instance had already been saved, the bulk create was failing when it tried to create a second (conjecture...), duplicate UpdateHistoryItem, due to the uniqueness constraints. This commit moves the `save()` into the non-postgres block, and allows the bulk_create action on the model to insert the objects for Postgres. My understanding is that the update_history needs to get saved regardless, since the `pending_recorded` attribute gets set. This doesn't seem to trigger a save because the ForeignKey relationship goes the other way. This solves the massive exception logging that occurs in my environment as a result of this problem, leading to maxed out memory and CPU usage on the server. Whether it correctly handles the data involved, I'm not clear enough on how this works to say with 100% certainty that this is all it needs.
With the sal-scripts v2.0, I get these all day long:
The text was updated successfully, but these errors were encountered: