You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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
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:
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).
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.
Yep sounds good. This should be the recommended approach within the documentation.
The text was updated successfully, but these errors were encountered:
Questions:
Answers:
The text was updated successfully, but these errors were encountered: