We don't update lp_person unless we need to ship new data to ISD, as altering that table will mean SSO downtime and coordinating with ISD.
If we keep the proposed schema, that means the lp_mirror_person_ins trigger needs to list the columns to mirror explicitly rather than using NEW.* in the same manner as lp_mirror_account_ins does.
Can we find a better place for this information rather than making the Person table even wider? On one hand, it is just another boolean. On the other, this information will be rarely used and should not slow down the common queries on the Person table or slow down deserialization of Person rows.
Perhaps a new table like SubscriptionSettings would be better, moving Person.verbose_bugnotifications to it along with this new column?
We don't update lp_person unless we need to ship new data to ISD, as altering that table will mean SSO downtime and coordinating with ISD.
If we keep the proposed schema, that means the lp_mirror_ person_ ins trigger needs to list the columns to mirror explicitly rather than using NEW.* in the same manner as lp_mirror_ account_ ins does.
Can we find a better place for this information rather than making the Person table even wider? On one hand, it is just another boolean. On the other, this information will be rarely used and should not slow down the common queries on the Person table or slow down deserialization of Person rows.
Perhaps a new table like SubscriptionSet tings would be better, moving Person. verbose_ bugnotification s to it along with this new column?