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

Add DateTimeType to search #419

Merged
merged 39 commits into from
Jun 22, 2021
Merged

Add DateTimeType to search #419

merged 39 commits into from
Jun 22, 2021

Conversation

epicadk
Copy link
Contributor

@epicadk epicadk commented Apr 2, 2021

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straighforward changes).

Fixes #375

Description
Clear and concise code change description.

Add date to search

Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?

Followed a similar approach to that of string and reference

Type
Choose one: Feature

Screenshots (if applicable)

Checklist

  • I have read and acknowledge the Code of conduct
  • I have read How to Contribute
  • I have read the Developer's guide
  • I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA
  • I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach
  • I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project
  • I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally
  • I have built and run the reference app(s) to verify my change fixes the issue and/or does not break the reference app(s)

@jingtang10
Copy link
Collaborator

Well done in figuring out how the index tables work.

@epicadk epicadk marked this pull request as ready for review April 3, 2021 20:28
@epicadk
Copy link
Contributor Author

epicadk commented Apr 3, 2021

Well done in figuring out how the index tables work.

Thankyou 😄. I'm not sure how I should handle the case when the Prefix is null should we throw an error or have a default value?

@epicadk
Copy link
Contributor Author

epicadk commented Apr 12, 2021

@jingtang10 I've added a test for the SQL query. But I think we should resolve #433 before we merge this. Converting to draft will add tests for all the cases. I just wanted to know whether I should continue adding the tests in FhirEngineImplTest or should I add them to DatabaseImplTest ?

@epicadk epicadk marked this pull request as draft April 12, 2021 19:12
@epicadk
Copy link
Contributor Author

epicadk commented Apr 19, 2021

@jingtang10 I've added a test for the SQL query. But I think we should resolve #433 before we merge this. Converting to draft will add tests for all the cases. I just wanted to know whether I should continue adding the tests in FhirEngineImplTest or should I add them to DatabaseImplTest ?

Hi, can I have some help here?

@jingtang10
Copy link
Collaborator

Hi @epicadk sorry for the delay. I approved and merged #433. Can you mark this draft as ready for review? thanks

@epicadk epicadk marked this pull request as ready for review April 19, 2021 14:47
@epicadk
Copy link
Contributor Author

epicadk commented Apr 19, 2021

Hi @epicadk sorry for the delay. I approved and merged #433. Can you mark this draft as ready for review? thanks

Marked as ready to review. But I haven't really added tests. I'm having trouble in figuring out where I should test if the query works as intended . Should I add the tests in the FHIRengineImpl test or the DatabaseImpl test?

@epicadk
Copy link
Contributor Author

epicadk commented Apr 23, 2021

Added an empty commit because build test was failing here but seemed to be working fine locally. If it fails again I'll look into it.

@epicadk epicadk marked this pull request as draft May 10, 2021 06:47
@epicadk
Copy link
Contributor Author

epicadk commented Jun 10, 2021

Hi @epicadk, could you please provide an ETA for completion of changes mentioned in the PR?

I think this and #436 are pretty similar. Once that is approved and ready to merge I'll make similar changes to this pr. I'd say we can get this done in the next 4-5 days

@Tarun-Bhardwaj
Copy link

@aditya-07 , could you please review the changes?

Copy link
Collaborator

@jingtang10 jingtang10 left a comment

Choose a reason for hiding this comment

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

Awesome! 😎

Thanks for the PR!

Copy link
Contributor

@deepankarb deepankarb left a comment

Choose a reason for hiding this comment

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

Thanks @epicadk this is cool!
I've left a few non-blocking comments. LGTM, approved 🚀

.apply {
filter(Patient.DEATH_DATE) {
prefix = ParamPrefixEnum.STARTS_AFTER
value = DateTimeType("2013-03-14")
Copy link
Contributor

Choose a reason for hiding this comment

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

The DateTimeType supplied above to patient has time zone but not here. Will running the query in different time zones produce consistent results?

Can we add tests for that case or create an issue to add them later?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, I have opened #567

): ConditionParam<Long> {
val (start, end) = value.rangeEpochMillis
return when (prefix) {
ParamPrefixEnum.APPROXIMATE -> TODO("Not Implemented")
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we add more details here about ParamPrefixEnum.APPROXIMATE e.g. link to spec and reason for not implementing.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, an issue to track it :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks opened #568 and added a link to the issue in the TODO

private val DateTimeType.rangeEpochMillis
get() = value.time to precision.add(value, 1).time - 1

private data class ConditionParam<T>(val condition: String, val params: List<T>) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use varargs for params?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can't use varargs in the primary constructor of a data class. I've created a secondary constructor for that reason. I realize I was still using listOf in the dateTime code, I've updated that now.

@epicadk epicadk merged commit 12c1163 into google:master Jun 22, 2021
@epicadk epicadk deleted the date_search branch June 22, 2021 04:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 High priority issue
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Support date and date time in search
7 participants