Adapt __str__ and __repr__ methods for DB
#11329
Conversation
This commit removes some debugging functionability in favor of production DB. `__str__` and `__repr__` methods won't be so descriptive now since we are removing some information from their rendering. This is because to render them properly we need to hit the DB multiple times in the worst case --generating 500 on some user requests that need to be logged in Sentry/New Relic. There are better ways for this: disabling logging on production and enabling it on DEBUG + Django Shell, but that requires more extra work that doesn't seems super priority right now. We can come back later and add them as we need them if we want. Closes #10954
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
This is probably all safe, but I did want to note that we have used the model's string representation in some of the UIs in templates. It would be worth a pass through the various admin pages for any signs of this. No particular model comes to mind at least though, so this is mostly safe I'm sure.
|
It seems there are some footer tests failing because of this. - 'project': 'Version 0.8.1 of Pip (19)',
+ 'project': '0.8.1',This comes from However, I think this is not super important because this is the footer API and we are not using the |
|
By the way, the |
This commit removes some debugging functionability in favor of production DB.
__str__and__repr__methods won't be so descriptive now since we are removing some information from their rendering. This is because to render them properly we need to hit the DB multiple times in the worst case --generating 500 on some user requests that need to be logged in Sentry/New Relic.There are better ways for this: disabling logging on production and enabling it on DEBUG + Django Shell, but that requires more extra work that doesn't seems super priority right now. We can come back later and add them as we need them if we want.
Closes #10954