Search Iterator as data option - complete?

[NicoN13]

Hi @s-cork

I saw this post from early last year: #19

Have you perhaps managed to implement search iterators as data options?

Thanks,

[s-cork]

If you read the readme you'll see app_table as an option. If not clear let me know what's missing.

[s-cork]

Happy to take a look at a clone link and see what we can do

[NicoN13]

I'll create a dummy app over the next day or so to show the challenge I'm having. Really appreciate the help by the way!

[NicoN13]

Hi @s-cork

Haven't had time yet to create a dummy app with large enough tables and linked rows to showcase the problem. But I've been thinking, could it be the use of cell.get_table_row() in the column formatters that causes the slow down?

So let's say I have 5 tables.
Table1 has a linked column to Table2. All other columns in Table1 are numbers, strings, and so on. The only link is to Table2.
Table2 has linked columns to Table3, Table4 and Table5.

The client readable table is as such.
return app_tables.table1.client_readable()

Then my initial query is:

initial_query = {
    q.fetch_only(
        *table1_columns,
        table2_link=q.fetch_only(
            "product_name"
        )
    )
}

So I'm saying only fetch all table 1 columns and fetch the single column in the linked table to which I'm interested ("product_name"). However, in my column formatters I need to apply some formatting to the product_name in order to display it correctly.
So in my column formatter, I say return cell.get_table_row()["table2_link"]["product_name"].upper() or any other conversion I might need to apply.

Could it be that calling cell.get_table_row() in effect fetches all columns and linked columns causing the slowdown?

[s-cork]

It shouldn't. It just return the row that was already fetched. If you start accessing columns that weren't included in fetch only it would slow down. But it doesn't sound like you are.

Have a look at the browser console and see if you're getting a lot of unexpected rpc call logs.

One rpc call represents one server fetch. If you're getting hundreds we know there's a problem.

Ideally you'd get one per fetch of the page_size.

[NicoN13]

I can confirm I'm only getting one rpc call with the load, so it's not that.