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-5140 Fix DataSetFileMeta / Add TimePeriodRangeMeta #4871

Merged
merged 2 commits into from
May 21, 2024
Merged

Conversation

mmyoungman
Copy link
Collaborator

Copy of this PR, since I accidentally blitzed my changes 😨

This PR fixes an issue where DataSetFileMeta only stored one TimeIdentifier for a whole data set. This assumption I made is incorrect - a data set can have multiple TimeIdentifier's e.g. months.

File.DataSetFileMeta now has a TimePeriodRangeMeta which stores the data set's starting and ending TimeIdentifier/Year.

We are finished with the DataSetFileMeta migration endpoint, so I repurposed it in this PR to set the new TimePeriodRange field and remove TimeIdentifier and Years.

The TimeIdentifier and Year fields in DataSetFileMeta can be removed after this migration. I've added a note to do so to EES-4918.

@mmyoungman
Copy link
Collaborator Author

mmyoungman commented May 17, 2024

Nick left a comment on the previous PR: #4868 (comment)

Would change this to string Period to match how we've modelled it in the public API.

We've purposefully done this because singular dates and date ranges are eventually coming down the pipeline ([EES-3109](https://dfedigital.atlassian.net/browse/EES-3109)).

These new time periods are potentially going in the time_period column, so the current assumptions that we make all over that this is a single numeric year are likely to be incorrect in the future. Modelling our meta summary as suggested helps prevent this being an issue later down the line.

I've changed Year to Period in TimePeriodRangeBoundMeta.

For clarity, the Year/Period here is coming from the Stats DB Observation table. Do we intend to migrate all observations so Year is no longer a thing? If not, then maybe it is best left as Year.

I've also added a new override to TimePeriodLabelFormatter.Format that takes a string period and parses it into an int year, which you might want to take a look at. I've had to a similar thing in DataImportService#WriteDataSetFileMeta. Not how these changes work with EES-3109 and/or if there is a better way for me to handle this for the future. If Observation.Year is going to change, it should blow up on that change as it'll try to parse an non-int into an int.

@ntsim
Copy link
Collaborator

ntsim commented May 17, 2024

In the future, yes it probably makes sense to do a migration to remove Year as we'd likely want to consolidate these into a single string Period column (or similar).

Will speak with you on Slack about your other changes!

Comment on lines 1845 to 1849
Start = new TimePeriodRangeBoundMeta {
TimeIdentifier = TimeIdentifier.CalendarYear,
Period = "2000",
},
End = new TimePeriodRangeBoundMeta {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Formatting for these open braces should be on new lines

Comment on lines 1603 to 1615
.WithTimePeriodRange(new TimePeriodRangeMeta
{
Start = new TimePeriodRangeBoundMeta
{
TimeIdentifier = TimeIdentifier.AcademicYear,
Period = "2000",
},
End = new TimePeriodRangeBoundMeta
{
TimeIdentifier = TimeIdentifier.AcademicYear,
Period = "2002",
},
})
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would be good to have some generator extensions for this to make this a bit nicer e.g. something like this:

_fixture.DefaultTimePeriodRangeMeta()
  .WithStart("2000", TimeIdentifier.AcademicYear)
  .WithEnd("2002", TimeIdentifier.AcademicYear)

Similar thing applies in the other test case further down

@@ -15,8 +15,11 @@ public static Generator<DataSetFileMeta> WithDefaults(this Generator<DataSetFile
public static InstanceSetters<DataSetFileMeta> SetDefaults(this InstanceSetters<DataSetFileMeta> setters)
=> setters
.SetGeographicLevels(new List<string> { "National " })
Copy link
Collaborator

Choose a reason for hiding this comment

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

We can change this and the other lists below to collection expressions i.e.

.SetGeographicLevels(["National"])

@@ -11,31 +12,52 @@ public class DataSetFileMeta
public List<string> GeographicLevels { get; set; } = new();
Copy link
Collaborator

Choose a reason for hiding this comment

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

This would probably be better as List<GeographicLevel> to provide type safety here.

In the public API model, we also store the level codes (the enum values) in the DB JSON e.g. NAT, LA, etc, rather than the labels. The codes are not supposed to be changed often, so they are a better choice for this.

This is a more flexible approach that allows us to change the labels we return in the view models, without having to change them in the DB.

Given that we're already running a new migration, would suggest we also update the geographic levels too to store the codes instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've made the change. I ended up doing it with Newtonsoft.Json - my rational being that's what we are currently using for all other ContentDbContext JSON stuff so this keeps it consistent.


public List<int> Years { get; set; } = new();
public TimePeriodRangeMeta TimePeriodRange { 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.

Mentioned in our chat - we can add required across the model properties here and below and remove any unneeded default values.

@@ -1641,12 +1652,15 @@ public async Task DataSetFileMetaCorrectlyReturned_Success()
dataSetFileMetaViewModel.GeographicLevels
.AssertDeepEqualTo(originalMeta!.GeographicLevels);

dataSetFileMetaViewModel.TimePeriod.AssertDeepEqualTo(
new DataSetFileTimePeriodViewModel
dataSetFileMetaViewModel.TimePeriodRange.AssertDeepEqualTo(
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 need AssertDeepEqualTo as we're using records, can use standard Assert.Equal

@@ -1641,12 +1652,15 @@ public async Task DataSetFileMetaCorrectlyReturned_Success()
dataSetFileMetaViewModel.GeographicLevels
.AssertDeepEqualTo(originalMeta!.GeographicLevels);
Copy link
Collaborator

Choose a reason for hiding this comment

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

As below - don't need deep equals, can just use Assert.Equal

originalMeta.TimePeriodRange.Start.TimeIdentifier),
To = TimePeriodLabelFormatter.Format(
originalMeta.TimePeriodRange.End.Period,
originalMeta.TimePeriodRange.End.TimeIdentifier),
});

dataSetFileMetaViewModel.Filters
Copy link
Collaborator

Choose a reason for hiding this comment

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

Similar to above - can just use Assert.Equal.

Same for indicators below as well!

@@ -1874,13 +1899,15 @@ public async Task FetchDataSetDetails_Success()
viewModel.Meta.GeographicLevels
.AssertDeepEqualTo(dataSetFileMeta!.GeographicLevels);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can just use Assert.Equal rather than deep equals.

Same thing for the other meta facets below as well.

@@ -3,14 +3,14 @@ namespace GovUk.Education.ExploreEducationStatistics.Content.ViewModels;
public record DataSetFileMetaViewModel
{
public List<string> GeographicLevels { get; init; } = new();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can add required on all these view model properties and remove any unneeded default value - here and below


namespace GovUk.Education.ExploreEducationStatistics.Common.Converters;

public class GeographicLevelsListJsonConverter : JsonConverter<List<GeographicLevel>>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Might want to change this to IList to make it more generic

@mmyoungman mmyoungman merged commit 930c76c into dev May 21, 2024
7 checks passed
@mmyoungman mmyoungman deleted the EES-5140-2 branch May 21, 2024 09:44
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