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

EES-5740 Backend work for filter hierarchies #5479

Open
wants to merge 4 commits into
base: dev
Choose a base branch
from
Open

Conversation

mmyoungman
Copy link
Collaborator

This PR implements the backend work needed to create filter hierarchies on the table tool page.

Filter hierarchies are saved in a new column on the Files table. This will soon be moved to the new DataSetFileVersion table when that is created.

It's possible we may want to not merge this until some of the frontend work has been done for this - it's possible the frontend might want the data in a different format and/or more information (like FilterItem labels, for example).

I've added three new test data sets for testing filter hierarchies.

@@ -9,4 +11,6 @@ public record SubjectMetaViewModel
public Dictionary<string, LocationsMetaViewModel> Locations { get; set; } = new();

public TimePeriodsMetaViewModel TimePeriod { get; set; } = new();

public List<DataSetFileFilterHierarchyViewModel>? FilterHierarchies { get; set; } = null;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't think you need to set an initial value of null on a nullable property. Also, since the other properties are auto-instantiated, you should be ok to add #nullable enable to this class without raising any warnings/changing anything else.

var childFilter = filters
.Single(f => f.GroupCsvColumn == parentFilter.ColumnName);

while (true) // one iteration of loop per tier
Copy link
Collaborator

@tomjonesdev tomjonesdev Dec 20, 2024

Choose a reason for hiding this comment

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

Just a minor point, but I don't think the purpose of this loop is particularly clear, especially since the logic which follows is quite complex. Perhaps it would help scanning/readability if you defined a named condition, and updated it per iteration as needed? Wouldn't need the comment then either, e.g.

var hasChildFilter = true;
while (hasChildFilter)
{
    ...
    hasChildFilter = false;
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This was actually how I originally had it (pretty much) but changed it thinking this would make it easier to follow the logic at the end of each loop iteration setting up the next.

I'll have a think about how this can be done - cause we've thought there is a slight issue here so probably worth it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants