-
Notifications
You must be signed in to change notification settings - Fork 5
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
base: dev
Are you sure you want to change the base?
Conversation
@@ -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; |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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;
}
There was a problem hiding this comment.
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.
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.