Skip to content
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

fix: raise notice to delete dependent fields after workspace reset #583

Merged
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions scripts/sql/functions/delete-workspace.sql
Original file line number Diff line number Diff line change
Expand Up @@ -327,6 +327,17 @@ BEGIN
RAISE NOTICE E'\n\n\n\n\n\n\n\n\nSwitch to prod db and run the below query to update the subscription';
RAISE NOTICE E'begin; update platform_schema.admin_subscriptions set is_enabled = false where org_id = ''%'';\n\n\n\n\n\n\n\n\n\n\n', _org_id;

RAISE NOTICE E'\n\n\n\n\n\n\n\n\nSwitch to prod db and run the below queries to delete dependent fields


rollback;
begin;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Remove unnecessary transaction block

The rollback and begin statements in the notice are unnecessary since these are just example queries to be run later. They should be removed to avoid confusion.

-rollback;
-begin;


delete from platform_schema.dependent_expense_field_mappings where expense_field_id in (select id from platform_schema.expense_fields where org_id =''%'' and type=''DEPENDENT_SELECT'');

delete from platform_schema.expense_fields where org_id = ''%'' and type = ''DEPENDENT_SELECT'';\n\n\n\n\n\n\n\n\n\n\n', _org_id, _org_id;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

The deletion order is correct, but additional cleanup may be needed

The verification reveals:

  1. The mapping_settings table has a foreign key constraint to expense_fields, but it's DEFERRABLE INITIALLY DEFERRED, which means the deletion order won't be affected
  2. The current deletion order (dependent mappings before fields) is correct
  3. However, you should also clean up any related mapping_settings records before deleting the expense fields

Suggested cleanup order:

  • Delete from dependent_expense_field_mappings
  • Delete from mapping_settings where expense_field_id matches
  • Delete from expense_fields
🔗 Analysis chain

Verify the impact of deleting dependent fields

The new cleanup steps for dependent fields should be verified to ensure:

  1. No other tables have foreign key dependencies on these records
  2. The deletion order is correct (dependent mappings before fields)
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential foreign key dependencies on dependent fields

# Search for foreign key references to dependent_expense_field_mappings
rg -i "foreign\s+key.*dependent_expense_field_mappings" 

# Search for foreign key references to expense_fields
rg -i "foreign\s+key.*expense_fields"

# Search for any other references to these tables that might indicate dependencies
rg -i "dependent_expense_field_mappings|expense_fields.*type\s*=\s*'DEPENDENT_SELECT'"

Length of output: 653


Script:

#!/bin/bash
# Let's check for any references to mapping_settings table and its relationship with expense_fields
rg -i "mapping_settings.*expense_field" -A 3 -B 3

# Also check if there are any other tables referencing expense_fields
ast-grep --pattern 'CREATE TABLE $_ (
  $$$
  FOREIGN KEY ($$$) REFERENCES expense_fields($$$)
  $$$
)'

# Check if mapping_settings table has any relation to DEPENDENT_SELECT type fields
rg -i "mapping_settings.*type.*DEPENDENT_SELECT" -A 3 -B 3

Length of output: 2782



RETURN;
END
$$ LANGUAGE plpgsql;
Loading