We've had an ongoing problem with email-related operations - email enqueue and email send audit - running afoul of column width problems in the message table (most recently https://apereo.atlassian.net/browse/SSP-2832#icft=SSP-2832). The fixes to date have just been to widen fields to values which we just hope will be wide enough.
More robust solutions:
1) Change to clob/text fields 2) Normalize storage
#1 is the fool-proof approach, but historically there have been performance issues with clob/text fields, especially for tables with multiple such fields, so a bit of research is in order. If there are problems in this area, one option might be to move the sent_* fields into a separate table which would never really need to be loaded - only written to when sending a message. (A Hibernate Component or otherwise lazily loaded one-to-one association might be another option here for keeping these columns in the same table.)
#2 would still have potential truncation issues, but the risk would be dramatically reduced b/c a) individual email addresses, even including 'real' names are much less likely than multiple email addresses to overflow a max width field and b) it's more reasonable to implement in-app silent truncation rules on single addresses rather than a list of addresses.
We've had an ongoing problem with email-related operations - email enqueue and email send audit - running afoul of column width problems in the
messagetable (most recently https://apereo.atlassian.net/browse/SSP-2832#icft=SSP-2832). The fixes to date have just been to widen fields to values which we just hope will be wide enough.More robust solutions:
1) Change to clob/text fields
2) Normalize storage
#1 is the fool-proof approach, but historically there have been performance issues with clob/text fields, especially for tables with multiple such fields, so a bit of research is in order. If there are problems in this area, one option might be to move the
sent_*fields into a separate table which would never really need to be loaded - only written to when sending a message. (A Hibernate Component or otherwise lazily loaded one-to-one association might be another option here for keeping these columns in the same table.)#2 would still have potential truncation issues, but the risk would be dramatically reduced b/c a) individual email addresses, even including 'real' names are much less likely than multiple email addresses to overflow a max width field and b) it's more reasonable to implement in-app silent truncation rules on single addresses rather than a list of addresses.