Hey Irvin - I haven't had time to look at your sample closely but here's my thinking based on a similar scenario I've encountered. When you invoke an action to Requery Model using "Get More", Skuid automatically cancels changes in that model prior to getting the additional data. In other words, you can't slipstream in new data without losing your edits. You can mimick this by directly calling updateData on the model. If you do, you'll get an exception. To avoid that, the "get more action" cancels changes before calling updateData. Unfortunately, the only work around I've come up with thus far is a snippet that works along the lines of:

1) Check model for the row needed based on Id2) If it's there, you're all set3) If it's not there, then have another model, set its condition, query it and then adopt the row back in to the model that you want "editable"

It's been discussed in the past to offer a "get more if not already there" so that situations like yours (and mine and likely some others) can get data on demand and allow edits to data already retrieved. +1 for that feature! :)

No problem Irvin, sounds like you are in the same camp as me. I forgot about the load all data on page load situation. It was the path we went down originally but our page loads were taking way to long. Our models have 150+ fields on them and there are lots of records involved so loading on demand is critical for us (and it sounds like you as well).

One other solution would be in your action sequence, check if the model is dirty and don't open the drawer until the user saves. Less than ideal of course but would technically work.

Skuid Team - A couple of thoughts along these lines:

1) Would really like to see a "get more if not already there" action added. Skuid offers incredible benefit with very rich pages - but with rich pages comes lots of data to marshal over the wire. Loading on-demand in to a dirty model would solve for this.2) For the automatic "cancel" in the requery getmore action, might be worthwhile to just let this fail with an exception when calling updateModel instead of automatically cancelling changes (or at least console.log). The automatic cancel of changes is not obvious where as an exception would be that could be caught during testing. 3) The work around to use a separate model functions as needed. That said, it can't be used declaritively and requires a snippet that is specific to that scenario. It's been talked about in the past but this would be another time when being able to define "custom actions" (similar to custom components) and use the in builder would drive a ton of value for page developers.