| commit | 6c97865a0472068a2e116690e0967f0fbb7edc5a | |
| author | Stephen Nielson <snielson@discoverandchange.com> | |
| Sat, 2 Sep 2023 13:16:12 +0000 (2 09:16 -0400) | ||
| committer | GitHub <noreply@github.com> | |
| Sat, 2 Sep 2023 13:16:12 +0000 (2 09:16 -0400) | ||
| tree | af9e8bb85d3d62d37eabe91d060b6a025abfbd72 | treesnapshot (tar.gz zip) |
| parent | 9e608841128aac14398bd1322150cb66010ea931 | commitdiff |
WIP Fixes #6800,#6799 fhir/std api sort/pagination (#6801)
* WIP Fixes #6800,#6799 fhir/std api sort/pagination
Add common _sort parameter that can be used in the _rest_routes
Add date,_offset,_limit query parameters to the /api/patient route
Added helper method QueryUtils::escapeLimit for escaping limit
parameters in SQL queries.
Changed standard api to return the links parameters if there are
paginated responses for the search (someone searched with the
_limit/_offset parameters).
Added to FhirPatientService the _lastUpdated search parameter that can
be used.
Changed FHIR api to support in the base service the ability to do a
searchForOpenEMRRecordsWithConfig method that will allow more customized
configuration options in the future in addition to the basic search
parameters. It currently supports pagination and sort order. Right now
only the patient service supports the options.
I modified the ResourceServiceSearchTrait to be able to handle the
_sort,_limit,_count parameters and put them all in a _config property
that is handled in the FhirServiceBase class to generate the search
config and pass it down to services that implement the
searchForOpenEMRRecordsWithConfig method.
This is a work in progress commit as the FHIR links in the bundles still
need to be populated. Also need to do more extensive testing with the
FHIR api on the sort order and _offset/_limit parameters.
Not sure I like seperating out the clause builder for the where clause
and having a separate functionality for the orderby / pagination pieces.
It might make sense to have it all in one central function governed by
the search parameters. Not sure if I like the centralization, or if it
violates the Separation of Concerns principle. Still thinking it
through but this is an initial stab at things. I really wish we had
done doctrine back when we started all of this as it feels very much
like we're getting further and further into reproducing all of the
goodies of the doctrine ORM. That'd be a major overhaul that would
require a good bit of funding unfortunately.
* Fixing unit tests and method signature.
* Style fixes
* WIP Fixes #6800,#6799 fhir/std api sort/pagination
Add common _sort parameter that can be used in the _rest_routes
Add date,_offset,_limit query parameters to the /api/patient route
Added helper method QueryUtils::escapeLimit for escaping limit
parameters in SQL queries.
Changed standard api to return the links parameters if there are
paginated responses for the search (someone searched with the
_limit/_offset parameters).
Added to FhirPatientService the _lastUpdated search parameter that can
be used.
Changed FHIR api to support in the base service the ability to do a
searchForOpenEMRRecordsWithConfig method that will allow more customized
configuration options in the future in addition to the basic search
parameters. It currently supports pagination and sort order. Right now
only the patient service supports the options.
I modified the ResourceServiceSearchTrait to be able to handle the
_sort,_limit,_count parameters and put them all in a _config property
that is handled in the FhirServiceBase class to generate the search
config and pass it down to services that implement the
searchForOpenEMRRecordsWithConfig method.
This is a work in progress commit as the FHIR links in the bundles still
need to be populated. Also need to do more extensive testing with the
FHIR api on the sort order and _offset/_limit parameters.
Not sure I like seperating out the clause builder for the where clause
and having a separate functionality for the orderby / pagination pieces.
It might make sense to have it all in one central function governed by
the search parameters. Not sure if I like the centralization, or if it
violates the Separation of Concerns principle. Still thinking it
through but this is an initial stab at things. I really wish we had
done doctrine back when we started all of this as it feels very much
like we're getting further and further into reproducing all of the
goodies of the doctrine ORM. That'd be a major overhaul that would
require a good bit of funding unfortunately.
* Fixing unit tests and method signature.
* Style fixes
17 files changed: