At this time we don't have a more clear way to reproduce this - a blink time_table did not reproduce the issue in earlier testing.
Some rollups created from a lastby seem to have inconsistent contents - some rows seem up to date, while others can appear to be still showing the update. In this example we use a table publisher and a lastby to produce an updating table controlled by the user, and a rollup which at some steps will clearly not have data consistent with the lastby table.
Note that expanding/collapsing/scrolling will get a fresh snapshot from the server, one which is apparently up to date again, so all tables must be left visible as directed. This was originally reproduced with many thousands of rows updated at a time, but in this example we will just update one row at a time.
Steps to reproduce:
Set up the tables - run this python in the web IDE
from deephaven.stream.table_publisher import table_publisher
from deephaven import dtypes
from deephaven import agg
from deephaven.table_factory import new_table
from deephaven.column import string_col
table_def = {
'id': dtypes.string,
'org': dtypes.string,
'batchid': dtypes.string
}
blink_table, publisher = table_publisher(name='repro', col_defs=table_def)
table = blink_table.last_by('id')
rollup = table.rollup(aggs=[agg.max_('batchid')], by=['org'])
Rearrange the UI so that all three tables are visible side by side
At this point we expect to see the same row in table as in rollup_table plus the expected hierarchy - there should be two rows, each with batchid=1. Instead, we see no rows.
Create another row via the table publisher, with a larger batchid (so that the "max" shows the new row at each level of the hierarchy
At this time we don't have a more clear way to reproduce this - a blink time_table did not reproduce the issue in earlier testing.
Some rollups created from a lastby seem to have inconsistent contents - some rows seem up to date, while others can appear to be still showing the update. In this example we use a table publisher and a lastby to produce an updating table controlled by the user, and a rollup which at some steps will clearly not have data consistent with the lastby table.
Note that expanding/collapsing/scrolling will get a fresh snapshot from the server, one which is apparently up to date again, so all tables must be left visible as directed. This was originally reproduced with many thousands of rows updated at a time, but in this example we will just update one row at a time.
Steps to reproduce:
Set up the tables - run this python in the web IDE
At this point we expect to see the same row in
tableas inrollup_tableplus the expected hierarchy - there should be two rows, each with batchid=1. Instead, we see no rows.batchid(so that the "max" shows the new row at each level of the hierarchyWe expect to see two rows here, both with batchid=2. Instead, we see two rows, with the "root" showing batchid=1, and the child with batchid=2.