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

Create a generic point component type #1436

Merged
merged 6 commits into from
Oct 10, 2024
Merged
Show file tree
Hide file tree
Changes from 5 commits
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
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
UPDATE moped_components SET is_deleted = true WHERE component_name = 'Project Extent - Generic' AND line_representation = false;
Copy link
Member

Choose a reason for hiding this comment

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

in the spirit of having the down migrations restore the DB to the previous state, i think the right move here would be to actually hard delete the component that the up migration created. obviously, that's going to fail if there are any moped_proj_components that reference the component, so here are a few ideas:

  • just acknowledge that the down migration will not work without manual intervention by the dev to deal with the extant moped_proj_components that reference it
  • write the down migration to also migrate the moped_proj_components to some other component type (like intersection improvement generic)
  • write the down migration to hard delete moped_proj_components which use this component type, yolo style

in any case, i don't think this is a big deal so i'm going to approve your PR! 🤷

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

cool - thanks for saying this, and i agree that the hard delete is the better call to get back to pre-up migration state. I'm going to make that change since the soft-delete/un-soft-delete felt weird in the first place! probably the reason my spidey sense was going off 🕷️


UPDATE moped_components
SET component_name = 'Project Extent - Generic'
WHERE component_name = 'Project Extent - Generic (linear)' AND line_representation = true;
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
UPDATE moped_components
SET component_name = 'Project Extent - Generic (linear)'
WHERE component_name = 'Project Extent - Generic' AND line_representation = true;

-- Insert new point component for generic project extent
INSERT INTO moped_components (component_name, line_representation, feature_layer_id)
SELECT
'Project Extent - Generic',
false,
5
WHERE NOT EXISTS (
SELECT *
FROM
moped_components
WHERE (component_name, line_representation, feature_layer_id) = ('Project Extent - Generic', false, 5)
);

-- Restore point type component if it was previously soft-deleted
UPDATE moped_components
SET is_deleted = false
WHERE component_name = 'Project Extent - Generic' AND line_representation = false;

-- Insert same work types for generic project extent point as exist for generic project extent line
WITH inserts_todo AS (
SELECT
mcwt.work_type_id AS work_type_id,
mc.component_id AS component_id
FROM
moped_component_work_types AS mcwt,
moped_components AS mc
WHERE
mcwt.component_id = 0
AND mc.component_name = 'Project Extent - Generic'
)

INSERT INTO moped_component_work_types (work_type_id, component_id)
SELECT
work_type_id,
component_id
FROM
inserts_todo
ON CONFLICT DO NOTHING;