What is the preferred method for using referenced/lookup data?

Anvil Q&A
1

My application loads a bunch of lookup data into memory when it starts.

The data at this time is a dictionary of object ids and the objects itself.

When I run a server operation, the lookup value is sometime required to be persisted in the DB.

  1. What is the preferred method to pass data between the client and server?
    Should we be passing the ids and do an object lookup on the server and save those references when adding a row or should we pass the object itself and save a lookup on the server?

  2. Is there a huge performance hit passing Anvil Row objects across the wire?

  3. On the client side, where are these objects stored? LocalStorage?

Thanks

2

Hello,

There has been lots of discussion on the forum about these concepts. This thread contains lots of suggestions:

2 Likes
3

Typically I send table rows as a list of dicts and include both the id and the row itself

def get_row_as_dict(row):
  row_as_dict = dict(row)
  row_as_dict['row'] = row
  row_as_dict['id'] = row.get_id()

rows_as_dicts = []
for row in app_tables.my_table.search():
  row_as_dict = get_row_as_dict(row)
  rows_as_dicts.append(row_as_dict)

return rows_as_dicts

I adapt this if I have linked rows that I also need to unpack.

I do it this way because I like the syntax for updating a table row

@anvil.server.callable
def update_row(row_as_dict):
  row = row_as_dict["row"]
  row.update(**{k:row_as_dict[k] for k, _ in row})

I also like to have the id just in case I need it. but also because I use the Tabulator dependency which works best with a unique identifier for row objects and the id seems the most sensible.

Getting a table_row by id is a quick lookup for anvil on the server so working with the id alone to get the table row won’t be a performance issue.

NB: you do need to know which table the row came from in order to look it up

4

We pass the LiveObject (i.e. the row) and use that for pretty much everything. Turns out the ID is pretty much unnecessary and if you need an ID to display, generating one using a module like uuid or random is fairly straightforward.

EDIT: The LiveObject is actually serialized on both ends of the wire so the overhead is minimal (local processing only). However getting and looking up an ID both require a database call. I would not use the get_id() method if you can avoid it. If you need an ID create a new column and for things like an argument or return value of a server callable, use the LiveObject.

5

here are some relevant threads about row_ids

and - don’t rely on its formatting: