Yes.
That’s the point of using Row objects. (One of the points.)
And that’s why I don’t use them.
# this triggers three round trips (if executed on the client)
row['column1'] = value1
row['column2'] = value2
row['column3'] = value3
# this is more efficient, because it updates 3 columns in one round trip
row.update(column1=value1, column2=value2, column3=value3)
A Row object is more than a smart database updater. It also caches / lazily loads some values. This can be managed by the fetch_only query arguments and by the accelerated table settings.
If you don’t want to expose some columns, you can use a view of a table, so the row contains only the columns of that view. And you can use a view to make a row read only.
I never send Row objects to the client. My server callables return data structures, usually lists and dictionaries, that the client uses to build some class instances. At this point the client has an object that knows what it needs to know to manage the UI and to call other server callables to save any edited data. I only save the whole object when I decide to save, for example when a user clicks on the Save button, and all the data related to that object, which often is spread across multiple tables, is saved in the same transaction.
The following code works because the Shipment class is iterable like a list, and returns dictionary-like objects (of the Crate class) that can be queried with both attributes and keys (see the AttributeToKey paragraph here):
# in the main form
self.shipment = Shipment(shipment_id)
self.data_grid_1.items = self.shipment
# in the template either
self.name_label.text = self.item.name
# or
self.name_label.text = self.item['name'] # this is DataGrid friendly
def save_button_click(self, **eventargs):
self.shipment.save()
In the code above, the Shipment class constructor makes one server call to load anything it needs in one round trip. It is iterable, so it can be used in a DataGrid, and the Crate objects it returns are dictionary-like, so they can be used with databinding.
The save method will send all the modified data to the server in one single round trip, and update all the rows of all the tables that need to be udpated.
This is the right thing to do, but it is not enough. You need to do the same permission check on the server side. Any respectable hacker can see and modify your client side code, and bypass any check and make any server call. But no one will be able to fool the checks made on the server side.