Child pages
  • The ViewFoundSet
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

A ViewFoundSet (since 8.4) is a foundset based on a QBSelect query object (since 8.4). A ViewFoundSet can be created by:

databaseManager.getViewFoundSet(String name, QBSelect query) 


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:

databaseManager.registerViewFoundSet(ViewFoundSet foundset) 

This will mean that that instance will be kept in memory for forms that have that datasource (set through the solution model in 8.4, next major release will have ViewFoundSet support in the developer itself). If you don't need it anymore:

databaseManager.unregisterViewFoundSet(String datasource) 

By default a ViewFoundSet will not react to databroadcast changes, you can enable that by calling:

viewfoundset.enableDatabroadcastFor(QBTableClause queryTable, int flags)

So for a specific QBSelect table like the main table or a join table, you can enable databroadcast. Depending on the flag(s) that is given certain stuff will happen or the pk's for that table should also be selected (besides the columns that you really wanted to query).

By default if only enableDatabroadcastFor(table) is called we will monitor only the columns for that table based on the pk that is also selected, So if a databroadcast comes in for that table, we look if we have that pk in our ViewFoundSet and update the columns that are changed, those columns could come from the existing RowManager/Record data we already have, then no query is done at all, but it could also result in a single query selecting the changed column by pk on that table. So this ViewFoundSet.MONITOR_COLUMNS flag should not result in a big performance hit.


These are the flags that can be currently used:

	/**
	 * 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_PRIMARY_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_PRIMARY_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.

 

  • No labels