Regarding migration problem.md

Problem

• Migration taking too long to completed, put pressure on CPU & causing problem on deployment

• Default backfill meaning that PG will try to update all old orders at once. As DB grows, the pain will grow also.

Solution

• is it wht we will recommend as a pattern later? wht is the conclusion, we never do NOT NULL in SQL level and only do default in model?
• plan to fill up existing value if we adopt this pattern? or plan to leave them NULL but handle by Scan etc, as a pattern we recommend?
• Any other options u considered before jumping into conclusion and a “fix” like this?

Other options to considered :

• Setting longer readiness waiting time for K8s → Can cause actual failure took longer to be fixed
• Setting a different steps ( initContainer ) for K8s → Take longer time, need more research, reliance on K8S

Solution

Short term

• Avoid using default, especially when adding new column on migrations ( for orders & trips table ).
• If not null is truly needed at DB level, consider manual backfill in chunks, then add alter not null default on later migration.
• If default is needed, consider add default at hook level. We could also define our own default: tag to inject this within the hook.

Long term

• Upgrading to PG 11 to avoid this problem.

Detail implementation of pg-go on zero / null values

• Default:'old' only works for new insert right? how about update? how about read? how about falsey value?
• If notnull is taken out, does it mean now before using those fields with non primitive types (where there’s a zero value), we need to check for null?

• Since we use use_zero tag, pg-go will insert default zero value according to type if value is set to nil. That means service_time is 0, while service_properties will be null object. Parsing NULL values of pg for empty columns of old orders will be parsed as zero values ( 0 for ServiceTime, empty map for ServiceProperties ), thus we don't need to check for nil values manually.