SSWConsulting / SSWConsulting/SSW.Rewards.Mobile
API - Resolve potential issues using dateTime.Now in mappings
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 37
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Description
cc: @william-liebenberg @lukecookssw @jasontaylordev
In one of our Automapper mapping profiles, we are using DateTime.Now:
.ForMember(dst => dst.PointsThisYear, opt => opt.MapFrom(src => src.UserAchievements
.Where(ua => ua.AwardedAt.Year == DateTime.Now.Year)
.Sum(ua => ua.Achievement.Value)))
This can present some issues when testing the query that's dependent on this DTO.
Options:
- Inject
IDateTimeinto the DTO ctor (will need an explicit default ctor and an attribute for serialization) - Map these fields explicitly in the query (use
Ignore()for these fields and make multiple database calls to get the additional data) - Don't use
ProjectToand map the whole DTO manually - ...?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the AutoMapper profile containing the PointsThisYear mapping and the DTO or query that uses ProjectTo. Reproduce the testing problem, then compare the listed time-source, explicit-query, and manual-mapping options; done means one chosen approach is implemented and the dependent query can be tested deterministically.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api, backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100