[FOLIO-1525] SPIKE: Revisit Location to Service Point Relationship Modeling Created: 24/Sep/18 Updated: 12/Nov/18 Resolved: 12/Oct/18 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Story | Priority: | P2 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Jeremy Huff |
| Resolution: | Done | Votes: | 0 |
| Labels: | core, sprint47, sprint48 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||||||||||||||
| Development Team: | Prokopovych | ||||||||||||||||||||||||||||||||||||
| Description |
|
Use cases to help with the modelling: https://folio-org.atlassian.net/browse/UICHKIN-17 Design document: https://docs.google.com/document/d/1csjNcoxYwKJD_PuIa_iykxGB4Tln0zdRBZs9WCzZkOs/edit?usp=sharing |
| Comments |
| Comment by Jakub Skoczen [ 25/Sep/18 ] |
|
Jeremy Huff to describe the possibilites and get feedback before we crate implementation issues for next week. |
| Comment by Cate Boerema (Inactive) [ 27/Sep/18 ] |
|
Just wanted to let you all know that the RA SIG is in agreement that all locations need at least one service point. To that end, we want to move the selection of a service point to the location record. I'll add a user story for this. |
| Comment by Jeremy Huff [ 28/Sep/18 ] |
|
Here is a google doc outlining the specifics of this topic. |
| Comment by Cate Boerema (Inactive) [ 01/Oct/18 ] |
|
Hi Jeremy Huff, this is blocking many features. When can we begin development? |
| Comment by Jeremy Huff [ 01/Oct/18 ] |
|
After reviewing the pros and cons of various representations of the service point to location relationship, Kurt Nordstrom and I have decided that all the use cases implicated here can be satisfied with the addition of a "primaryFor" array of location ids to the service point entry. Once this is done, business logic will be used to expose manipulation of that array from both the service point and location interface implementations. This will allow for the support of the use cases described in the user stories. |
| Comment by Cate Boerema (Inactive) [ 02/Oct/18 ] |
|
Thanks Jeremy Huff and Kurt Nordstrom. I just want to confirm that you reviewed the use cases in this issue, as well:
Also, did you see the new user story about changing how location to service point relationships are assigned?
Thanks! |
| Comment by Jakub Skoczen [ 04/Oct/18 ] |
|
Jeremy Huff Adam Dickmeiss I'd like to make sure that we perform the "look-up-and-update" in a consistent manner, e.g within a transaction. |
| Comment by Jakub Skoczen [ 08/Oct/18 ] |
|
Guys, do we have implementation issues filed for this? |
| Comment by Jeremy Huff [ 08/Oct/18 ] |
|
Are
I am just about to put in a PR for a MODINVSTOR-177-breaking-changes branch. On this branch I decided to explore reversing the relationship, to avoid having to do as many transactions, and it turned out very well. I am now of the opinion that this is the desired relationship, and the branch I have should cover the use cases. Additional issues that might be created will be creating a constraint which disallows the addition of non existed ServicePoint UUIDs to a Location, and to cascade the deletion of a Service Point to Location. In regards to the later, we will need to decide if we want to allow the deletion of a service point which is in use on a location. |
| Comment by Cate Boerema (Inactive) [ 09/Oct/18 ] |
I think we should allow this but only when the service point is not primary for the location. There should be a warning, as well. I can draft a story for this:
|