Skip to content

Provide filled out item data when returning hold list#224

Merged
kenoir merged 8 commits intomainfrom
fill-item-requests-api
Aug 13, 2021
Merged

Provide filled out item data when returning hold list#224
kenoir merged 8 commits intomainfrom
fill-item-requests-api

Conversation

@kenoir
Copy link
Contributor

@kenoir kenoir commented Aug 12, 2021

Put the full item into a holds list for the front-end.

Closes #223

.map {
case Left(elasticError) =>
warn(s"Unable to look up $hold in Elasticsearch")
case Left(elasticError: ElasticsearchError) =>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Previously we just chucked this error, not sure why - i've added it to the warning here.

item = new DisplayItem(
id = hold.canonicalId.map { _.underlying },
identifiers = Some(List(DisplayIdentifier(hold.sourceIdentifier)))
// TODO: This .get should always be Some here
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll refactor this next, but to speed up getting this data into the front-end we could merge this PR, deploy and put the refactor into a new PR.

@kenoir kenoir marked this pull request as ready for review August 12, 2021 16:09
@kenoir kenoir requested a review from a team August 12, 2021 16:12
warn(s"Unable to look up $hold in Elasticsearch")
case Left(elasticError: ElasticsearchError) =>
warn(
s"Unable to look up $hold in Elasticsearch: ${elasticError}"
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's not address it here for the sake of getting this PR out quickly, but having a sourceIdentifier on the hold feels a bit odd to me – a hold is a thing in Sierra and could have a source identifier, it's just not the identifier we're using here.

Copy link
Contributor

Choose a reason for hiding this comment

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

What will happen in this branch if we can't find the item?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

but having a sourceIdentifier on the hold feels a bit odd to me

I agree, we use it to look up the item later and fill the Item option on StacksHold which itself feels wrong. I expect that it'll get removed refactoring out the .get.

What will happen in this branch if we can't find the item?

Good point. I think this is actually a case that will blow up the .get on the option added in this PR (theStacksHold is returned with a None for an Item. It's still quite unlikely but we should handle this by doing a multi-item get and returning a list of the items we can get while logging that things are missing with a warn.

| "type" : "Identifier"
| }
| ],
| "title" : "${titleString}",
Copy link
Contributor

Choose a reason for hiding this comment

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

nit:

Suggested change
| "title" : "${titleString}",
| "title" : "$titleString",

@kenoir kenoir merged commit bad6071 into main Aug 13, 2021
@alexwlchan alexwlchan deleted the fill-item-requests-api branch August 13, 2021 08:11
@kenoir kenoir mentioned this pull request Aug 13, 2021
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.

Return Item titles from Requests API

3 participants