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

HAPI client: Allow searches (returning a Bundle) to specify the custom resoure type to return #315

Closed
sreinst1 opened this Issue Mar 18, 2016 · 6 comments

Comments

Projects
None yet
2 participants
@sreinst1

sreinst1 commented Mar 18, 2016

Currently, using "custom resources" (http://www.google.com/url?q=http%3A%2F%2Fjamesagnew.github.io%2Fhapi-fhir%2Fdoc_extensions.html&sa=D&sntz=1&usg=AFQjCNFG1zOo2Czygw16878T1t0vU8gDSA)
is not working during searches that return a Bundle. The "custom resource" type to search for is specified in the search, but the returned Bundle contains other types.
Please fix so that the requested type be returned.
Note that custom resources work fine in reads.

See Google group discussion for reference:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/hapi-fhir/3GYsvpgYwvY/qW42OBbfJAAJ

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Mar 22, 2016

Ok, good news- I took a crack at this on a long train ride this week and it ended up working out (I think) quite well.

I'm going to check in a fix shortly. It won't be available until I push a new snapshot build which will probably happen next week (I'm on the road this week) but you can try it out before that by building HAPI from source locally.

Basically I've added a new method to FhirContext called setDefaultTypeForProfile which lets you declare a default type to use for a given resource profile. If a resource is being parsed by itself or in a bundle and it claims to conform to that profile via its metadata statement, the given type will be used instead.

Would be interested to hear your thoughts on whether this works for your use cases...

@sreinst1

This comment has been minimized.

sreinst1 commented Mar 22, 2016

Sounds great in general, but currently we don't (yet) make use of profiles.
In addition, as I wrote in my original post, the search itself already
specifies the desired resource type; that's why I expected it to work the
same way that it works in READ requests.

Thanks,
Shlomy

On Tue, Mar 22, 2016 at 12:45 PM, James Agnew notifications@github.com
wrote:

Ok, good news- I took a crack at this on a long train ride this week and
it ended up working out (I think) quite well.

I'm going to check in a fix shortly. It won't be available until I push a
new snapshot build which will probably happen next week (I'm on the road
this week) but you can try it out before that by building HAPI from source
locally.

Basically I've added a new method to FhirContext called
setDefaultTypeForProfile which lets you declare a default type to use for
a given resource profile. If a resource is being parsed by itself or in a
bundle and it claims to conform to that profile via its metadata statement,
the given type will be used instead.

Would be interested to hear your thoughts on whether this works for your
use cases...


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#315 (comment)

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Mar 22, 2016

Oh, that's an interesting point actually. Yeah, I guess if you explicitly say you are searching for your custom type right in the search request it would make sense for it to use that too.

What you're saying still wouldn't work.. Although the newly checked in code would at least give you a way of achieving what you want. I'm going to reopen to get the other way working too.

@jamesagnew jamesagnew reopened this Mar 22, 2016

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Mar 25, 2016

Ok, now what you are proposing will work too. Good idea!

Will push a new 1.5-SNAPSHOT build this weekend, or you can build from source anytime.

@sreinst1

This comment has been minimized.

sreinst1 commented Mar 25, 2016

Great, thanks! I will check it next week, but I probably won't use it until
1.5 is released. Is there a planned date for this?
Thanks,
Shlomy

On Fri, Mar 25, 2016 at 2:06 PM, James Agnew notifications@github.com
wrote:

Ok, now what you are proposing will work too. Good idea!

Will push a new 1.5-SNAPSHOT build this weekend, or you can build from
source anytime.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#315 (comment)

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Mar 25, 2016

It'll be soon for sure. A few weeks tops, if not less, depending on our schedule over here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment