Page History
...
This will return a ViewFoundSet object that has as datasource: "view:[name]". This foundset will have a different API then the normal JSFoundSset, it has the basic stuff like getSize(), getRecord(), forEach(), loadAllRecords() but no find/search support (just create a new ViewFoundSet with the updated QBSelect), or new/delete record.
Because it is just based on a QBSelect you can query from many tables a set of data at once. So using this can be a big improvement for showing table data that normally would show related data through relations or through a valuelist or aggregates from a join table.
If you want to use a ViewFoundSet on a Form, you can create one and then register this to the system:
...
| Code Block | ||
|---|---|---|
| ||
/**
* listen for column changes of the given table/datasource.
* This is used by default if you just use enableDatabroadcastFor() without flags.
* If you use the one with the flags you need to give this one if you just
* want to listen to column changes that are in the result for a given datasource and pk.
* This constants needs to have the pk's selected for the given datasource (should be in the results)
*/
ViewFoundSet.MONITOR_COLUMNS;
/**
* listen for column changes of the given table/datasource in the join statement
* Like order_lines.productid that has a join to orders and is displaying the productname.
* If a change in such a join condition (like order_lines.productid in the sample above)
* is seen then the query will be fired again to detect changes.
*/
ViewFoundSet.MONITOR_JOIN_CONDITIONS;
/**
* listen for column changes of the given table/datasource that are used in the where statement.
* Like order_lines.unit_price > 100. If a change is seen on that datasource on such a column used
* in the where a full query will be fired again to detect changes.
*/
ViewFoundSet.MONITOR_WHERE_CONDITIONS;
/**
* listen for inserts on the given table/datasource.
* This will always result in a full query to detect changes whenever an insert on that table happens.
*/
ViewFoundSet.MONITOR_INSERT;
/**
* listen for deletes on the given table/datasource.
* This will always result in a full query to detect changes whenever an delete on that table happens.
*/
ViewFoundSet.MONITOR_DELETES;
/**
* listen for deletes on the given table/datasource which should be the primary/main table of this query.
* If a delete comes in for this table, then we will only remove the records from the ViewFoundSet
* that do have this primary key in its value. So no need to do a full query.
* So this will only work if the query shows order_lines for the order_lines table,
* not for the products table that is joined to get the product_name.
* Only 1 of the 2 monitors for deletes should be registered for a table/datasource.
* This constants needs to have the pk's selected for the given datasource (should be in the results)
*/
ViewFoundSet.MONITOR_DELETES_FOR_PRIMAIRY_TABLE;
/**
* listen for aggregates that are in the results of the given datasource.
* This means that when there are updates on that specific column where the aggregate is on
* or deletes, inserts on give datasource, a full requery will happen to refresh the aggregate.
*/
ViewFoundSet.MONITOR_AGGREGATES; |
So some like MONITOR_COLUMNS or MONITOR_DELETES_FOR_PRIMAIRY_TABLE will not have a big impact on performance but the others could have a larger impact because of the full queries that are done then when a change is seen to update the ViewFoundSet.
Besides monitoring for databroadcast, the ViewFoundSet can als be updateable by using one of the 2 save() functions on it. There is one requirement for this and that is that for all the columns that you change in a ViewRecord of a table, you also have to have the pk selected for that table in the QBSelect. So that Servoy can generate an update statement to the table with the changed columns for that pk.
If you change data in a ViewFoundSet then all the refreshes based on the databroadcast flags (and also loadForMoreData, so loading in then next 200 records) will be postponed until you save the changed Records. This works this way because we can't do a query to update/add more records because we don't know what the changed record exactly is, how it maps on the new data.
Overview
Content Tools
Activity