Stephen,

Model Upserts is an idea we’ve talked about for a while, but it would be helpful for us to have some examples of how customers would envision using Model Upserts within Skuid, to help us determine the boundaries of what we would implement. Are you chiefly envisioning upserts being used for importing data, or do you have other use cases?

Outside the context of importing data into Salesforce, I imagine upserts being useful as part of a new record creation process in preventing duplicate data from being entered, or in eliminating the need to query to find out whether certain records already exist. Is this what you’re thinking? 

That’s exactly right Zach. In our case we’re not doing imports (although I’m sure that will come up eventually) we’re building a custom mass insert/update UI and trying to use models and table components to present a simple spreadsheet-like interface that let our users mass enter data that updates records that may or may not exist in Salesforce (e.g. like doing a stock take). Taking a broader view we have a few cases of advanced UIs that merge, transform and enrich data from multiple models, external APIs and user input and summarise this data into a unique record that we update in a “hidden” model not seen by the user.  

I know we can always do the extra work of querying before update but that results in “unnecessary” code and additional round-trips (for query, then update, then insert) compared to having a single upsert call. Given we’re building mass edit UIs on iPads running over a mobile data network which means they are already a little sluggish (especially createrow which I’ll raise a separate issue for) we want to minimise network trips and looping over records.

Hope that makes sense. We know we are pushing some boundaries with Skuid here so appreciate your need to understand how far this needs to go. We also do a lot of standard Salesforce Apex and API development so are also very used to (and bias towards) the convenience of the upsert!