VERSION_MISMATCH creates more work!

Questions
1

I’m wondering about the real benefits of catalog item versioning. It seems to create more work, for no particular benefit.

At the moment, the version is required in order to update any object. This means that the version must be retrieved and stored for every item as it’s created. The problem is that for nested items there’s no easy way to retrieve this version.

For example, creating a product with nested variations means that we need to use the id_mapping to map our client object id to the system generated id for each variation. We then need to use the generated id to trawl through the response data to find the matching variation and then extract the version from that before it can be saved.

If a version is going to be required for every update, why can’t the version be returned in the id_mappings structure to make it easy to find, since we need to save both the system id and the version?

An improvement would be to define a version of “0” which means just update the latest version because we don’t care about versioning. In some scenarios, the data is being synced from a database to the Square catalog, and the catalog should never be updated independently. In this case, we always want to just update the latest version.

As a work around, we’ve just resorted to retrieving the item from the catalog every time to get the version before updating it, so there’s no need to store the version. However, this all creates an extra load on the system and slows things down, so it would be nice if there were an easier way to do this.

2

I mentioned this in the previous post but listening to catalog webhooks to keep the object current in you’re database will reduce the load of bringing in all the objects just before updating the objects since the latest version of the catalog object is required. :slightly_smiling_face:

3

I can’t really see how this helps much in our situation. We have a multi-tenant architecture, so we’d have to work out how to correlate the webhook with the right customer account. It can probably be done, but it doesn’t make life easier.

At the end of the day, we end up needing to retrieve the object to determine if is exists (due to the lack of a true upsert and symbolic handles) and then using the version retrieved to then update the object.

It would be nice if this additional API call could be eliminated, and I’d certainly like to see it added to your feature requests list.

4

Right, the merchant_id is in the payload of the webhook. Also when you OAuth a merchant you’re given the access token and merchant_id. You can take the merchant_id in the webhook payload and match it to the merchant_id from OAuth to get the access token you’ll need to call the Catalog API to update the objects. :slightly_smiling_face:

5

Following up from my observation that the versioning of the catalog adds an unnecessary complexity when it’s not needed, I now am seeing version mismatches that I can’t explain.

My logic is pretty simple. Issue a ‘retrieve_catalog_object’ to get the catalog object, update the fields which have changed, then write the data back with ‘upsert_catalog_object’.

The problem is that this returns a ‘Object version does not match latest database version’ message. I don’t understand this. I have just retrieved the version from the database, and then used the same value to update the database. Why is this being rejected?

For example, I retrieve the following object -

{:type=>“ITEM_VARIATION”, :id=>“G5B6EUVNK4HUATLUR3QO2WPK”, :updated_at=>“2022-09-26T23:57:35.273Z”, :created_at=>“2022-09-26T22:54:01.004Z”, :version=>1664236655273, :is_deleted=>false, :present_at_all_locations=>true, :item_variation_data=>{:item_id=>“AMNVOIFAUTABCSAVTVNLQGUZ”, :name=>“Pink”, :sku=>“12345678”, :ordinal=>1, :pricing_type=>“FIXED_PRICING”, :price_money=>{:amount=>12200, :currency=>“AUD”}, :location_overrides=>[{:location_id=>“JKR7SPNZZH19N”, :track_inventory=>true}], :track_inventory=>true, :sellable=>true, :stockable=>true}}

I then use the following data to update the catalog -

{:idempotency_key=>“677765cc-4957-4c2e-9c57-eeb58f893322”, :object=>{:type=>“ITEM_VARIATION”, :id=>“G5B6EUVNK4HUATLUR3QO2WPK”, :updated_at=>“2022-09-26T23:57:35.273Z”, :created_at=>“2022-09-26T22:54:01.004Z”, :version=>1664236655273, :is_deleted=>false, :present_at_all_locations=>true, :item_variation_data=>{:item_id=>“AMNVOIFAUTABCSAVTVNLQGUZ”, :name=>“Pink”, :sku=>“12345678”, :ordinal=>1, :pricing_type=>“FIXED_PRICING”, :price_money=>{:amount=>12200, :currency=>“AUD”}, :location_overrides=>[{:location_id=>“JKR7SPNZZH19N”, :track_inventory=>true}], :track_inventory=>true, :sellable=>true, :stockable=>true, :upc=>“”, :user_data=>nil}}}

This fails with the version mismatch error. What is wrong with this?