Table => Max records?

[xX-Nexus-Xx]

Description

Hi, I'm using your table to show a history of events and commands.

I used the 'Append' action to see the full history. I had several of these views (e.g. per Room, per Sensor)

Unfortunately, I ended up with (10+)thousands of records per table (persistent storage), resulting in a huge memory usage and resulting in a very laggy/unresponsive environment.

Is there an option to specify the number of records (or max memory usage) .. or can this feature be added ?

thanks for considering

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[bartbutenaers]

@xX-Nexus-Xx ,

I could add an option to show only the first N records in the ui table, but then the ui table node needs to determine which records does the ui table needs to show:

• The last N records
• The first N records
• ...

That feels somehow a bit wrong to me. Imho the ui table should show all records that you pass to him, otherwise you have an incomplete view (which I personally wouldn't trust). It seems to me that it is better to filter away the unnecessary records while querying, or after querying in a separate node (which is a bit more less performant). But that in both cases you pass to the ui table node only the records that you want to show.

However I assume you have already thought about those options I assume?
Bart

[colinl]

Since @xX-Nexus-Xx is using the table in append mode I wonder whether the requirement is to drop rows from the front as new rows are added at the end, once a limit is reached. I can see that being useful in some cases.

[bartbutenaers]

@colinl
Thanks for thinking out loud!

Yes indeed that seems to be a good use case. I had interpreted it incorrectly: that he loaded a massive amount of records at a time, and appended all of those to the ui-table in some kind of batch processing flow...

I will add this feature as soon as I have time. @Steve-Mcl you can assign this one to me.

[xX-Nexus-Xx]

@bartbutenaers , thank for considering. In most of my use-cases I fill a FiFo buffer and use the "REPLACE" option, but there are certain zenarios where the "APPEND" option is easier (not necessarily better) and than a max record count would be ideal ;)

thx a lot

[Steve-Mcl]

To be clear on the specification, are we saying:

• in append mode, an optional limit what FIFOs out old records from the store when exceeded
• by default, there will be no limit? (Or an arbitrary value?)
• in replace mode, there will be no limit available to set

[bartbutenaers]

@Steve-Mcl
Imho you simply specify a limit that specifies how many records are stored inside the table. Independent whether you specify the records in bulk at once, or you append rows to an existing set. When more rows are supplied as the limit, we throw away the oldest/first rows.

By default the limit is 0 which means no limit.

In replace mode the limit will also be available, but it wouldn't do anything since the number of rows doesn't change.

[bartbutenaers]

@xX-Nexus-Xx
It would really help if you could share a simple example flow which I can use to:

• specify a bunch of records at once
• append some rows

That would save me some time... Thanks!!