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

Document ClientId, OpportunityJsonLdId and OfferJsonLdId in FakeDatabase #175

Open
nickevansuk opened this issue Nov 30, 2021 · 0 comments

Comments

@nickevansuk
Copy link
Contributor

Questions:

  1. On the FakeDB OrderItem table, there is a ClientId property, but am I right in thinking that the ClientId on the Order will suffice there? IE, it's not possible the same order to have order items with different ClientIds on them?
  2. The OrderItem has OpportunityJsonLdId and OfferJsonLdId properties - but am I right in thinking that as long as the opportunity ids are unique across the db, I could store the identifier here instead of the whole id url? IE, store "ven_000225-rbt_00010-20210521090000-PT1H" (which is a slot id) as that will be unique across all our opportunities
  3. What I will probably want to do is add a "BookingId" to the OrderItem table which contains the actual Id of the booking row in the booking system that I will be creating as part of this

Answers:

  1. Yes the ClientId on the Order will suffice. Add to the documentation, spec and ref impl that it is not expected that duplicate GUIDs can exist across Client Ids (as this would force every system to use a compound key), but rather it is expected that if a particular GUID is in use, it should be retried. It is also recommended that a fully random GUID be used (v4).
  2. The only reason they’re in OrderItem is for the feed generation - makes it easier to generate the feed (as the OrderFeed doesn’t have access to the IdTemplates needed to generate the various types of IDs), and those IDs can’t change in future. This should be fully documented within the FakeDatabase and the points in the code that create these IDs.
  3. Yep sounds good. This should be the recommended approach within the documentation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant