In This Chapter
The Servoy Foundset is a developer's window into Servoy's Data Binding layer. A single foundset always maps to a single database table (or view) and is responsible for reading from and writing to that table. From the user interface, a foundset controls which records are loaded and displayed, as well as how records are created, edited and deleted. From the developer's perspective, a foundset is a programmable object with specific behaviors and run-time properties that provide a high-level abstraction to facilitate low-level data operations.
For all programming reference information, see the JSFoundSet API documention in the reference guide.
A Servoy Form is typically bound to a single database table and the form will always contain a single foundset which is bound to the same table. Much of the action in the user interface, such as a user editing data fields, directly affects the form's foundset. Conversely, actions taken on the foundset, such as programmatically editing data, is immediately reflected in the form.
While a form is always bound to a foundset, a foundset may be used by zero or more forms. Foundsets can be created and used by a programmer to accomplish many tasks.
Often, there can be several different forms which are bound to the same table. In most cases the forms will share the same foundset and thus provide a unified view. For example, imagine a form showing a list of customer records, where clicking on one of the records switches to another form showing a detailed view of only the selected record. The forms will automatically stay in sync and there is no need to coerce the forms to show the same record. Exceptions to this behavior include scenarios where forms are shown through different Relations, or have been explicitly marked to use a separate foundset.
See also the namedFoundset property of a form.
One of the primary jobs of a foundset is to load records from the table to which it is bound. A foundset is always based on an underlying SQL query, which may change often during the lifetime of the foundset. However the query will always take the form of selecting the Primary Key column(s) from the table and will also always include an
ORDER BY clause, which in its simplest form will sort the results based on the Primary Key column(s).
After retrieving the results for Primary Key data, the foundset will issue subsequent SQL queries to load the matching record data in smaller, optimized blocks. This query happens automatically in an on-demand fashion to satisfy the foundset's scrollable interface.
A foundset's underlying query can change dramatically throughout the client session. The following events will modify a foundset's underlying query:
Themethod is used to directly modify the underlying query that loads PK data. There are several uses.
This is the simplest approach, which loads a single recordy by its primary key value.
This approach simply dictates that a foundset will load records based on specified primary key data.
Notice the array was converted first to a JSDataset object. This object, which is like a 2-dimensional array, is used to provide support for composite primary keys.
This approach is useful to essentially copy the query of another foundset.
This approach allows a SQL query fragment to be used to set the foundset's underlying query. There are certain restriction on the form that a query can take. For obvious reasons, the query must return the primary key column(s) from the table to which the foundset is bound. For a full description see the reference guide.
See also the loadRecords API in the reference guide for complete usage options.
All foundsets contain a sorting definition that determines the order in which records are loaded and displayed. Sorting is always expressed in the ORDER BY clause of a foundset's query and thus handled by the database.
Parameters for this property include an ordered list of one or more data providers, each of which having a sort direction, either ascending or descending. The string takes a form such that each data provider and its sort direction are separated by white space. The direction is abbreviated either asc or desc. Multiple data providers are separated by commas.
Example: Sort String Format
The order of the data providers determines their relative priority when sorting, such that when two records contain the same value for a higher priority data provider, the sorting will be deferred the next lowest priority data provider.
Example: The following sort string will sort, first on last name, and second on first name.
The result is that all records are sorted by last name. But in the case where the last names are the same, then the first name is used.
|| last_name || first_name ||
Available Data Provider Types
The following data provider types may be used as sort criteria:
Example: Sort a customers foundset based on the number of orders each customer has, in this case a related aggregation.
Results in the following query:
Sorting on related columns and aggregates changes is simple and powerful. However this changes the nature of the foundset's query. One should be advised of this and ensure that the database is tuned accordingly.
The foundset maintains a scrollable interface for traversing record data. This interface includes a numeric index for every record that is returned by the foundset's query.
The foundset also has a
size property, which indicates the number of records that are indexed by the foundset at any given time. Because the foundset's SQL query may eventually return thousands or millions of results, the initial size of the foundset has a maximum of 200. This value can grow dynamically, in blocks of 200, as the foundset is traversed.
The foundset maintains a selected index, a cursor with which to step through the records. If the selected index equals or exceeds the size of the foundset, the foundset will automatically issue another query to load the next batch of primary key data. Thus the foundset loads record data and grows dynamically with the changing Selected Index property. There are two methods used to get/set the foundsets selected index. They are getSelectedIndex and setSelectedIndex respectively.
Example: In the example below, note that the foundset's size changes after the selected index has changed. The foundset's cache grows dynamically
Often, as part of some programming operation, it is necessary to iterate over a part or all of a foundset.
There are several approaches to iterating: using the foundset iterator, changing the selected index of the foundset, accessing a record object, accessing data provider values as an array.
While the last three iterating options are more intuitive, and also vary with regards to performance and usage, the foundset iterator is the most recommended to be used since it is the only option that ensures iterating over all the records of the foundset, without missing any of them due to the multiple clients performing changes on the same foundset at the same time.
It is also possible to use JSFoundsetUpdater API to iterate over and update a foundset, though iterating is not its main goal.
Sometimes there is more than one user working on the same foundset, possibly inserting or deleting records. When iterating on a foundset, it needs to be ensured that the loop neither skips nor processes twice any record due to the foundset modifications occurred from other clients. Thus, in such cases, a secure iterator is needed to perform the iteration on the foundset.
forEach method does exactly that, iterating over all the records of a foundset and calling the callback method given as parameter for each one of them.
Example This is an example of how to use the
forEach method for iterating over a foundset.
See also the JSFoundset's
Perhaps the most intuitive approach is to programmatically change the foundset's selected index property.
Example: The example below iterates over the entire foundset using a for loop.
See also the JSFoundset's setSelectedIndex method.
While setting the selected index of the foundset is sometimes necessary, it also contains some overhead and therefore is not always the most efficient way to iterate over a foundset. However, one can iterate in a similar manner, access a record object without changing the selected index of a foundset by using the
getRecord method of the foundset.
Example This example iterates over the foundset, but does not affect the selected index. The performance will be better than the previous example, and will not have any side effects in the UI if the foundset is bound to a form.
See also the JSFoundset's getRecord method.
Sometimes the purpose of iterating over a foundset is to access all the values for a particular data provider. The most efficient way to do this is to obtain an array of values for the foundset's data provider using the
getFoundSetDataProviderAsArray method of the
Example This example shows how to access all the values in a foundset for a single data provider. Iterating over a simple array offers better performance over normal foundset iteration.
See also the JSFoundset's getFoundSetDataProviderAsArray method.
Foundsets are often constrained or filtered by a Relation. In this situation, the foundset is said to be a Related Foundset and its default SQL query will include in its
WHERE clause, the parameters by which to constrain the foundset.
It is important to make the distinction that a relation and a foundset are not one in the same. Rather, a relation name is used to reference a specific foundset object within a given context. The context for a related foundset is always a specific record object. But for convenience, related foundsets may be referenced within a form's scripting scope and as a property of any foundset. However in these cases, the context is always implied to be the selected record in the context.
Take a predefined Relation, customers_to_orders, which models a one-to-many relationship between a customers table and an orders table. The following three lines of code, executed within the scripting scope of a form based on the customers table, all produce the same result.
Related foundsets can be chained together using relation names. Again, the shorthand implies the context of the selected record for each foundset.
A foundset may be automatically updated when the client receives a Data Broadcast Event . If the data change affected the table to which the foundset is bound, the foundset will be refreshed to reflect the change.
Foundsets are typically updated on a record-by-record basis, either as the user operates on a foundset-bound GUI component, or through programmatic interactions. However, sometimes it is necessary to perform an update to an entire foundset. For performance reasons, it is not advised that this be done by programmatically iterating over the foundset's records. Rather, it is recommended that batch updates be performed using the JSFoundsetUpdater API.
The Foundset Updater API is ideal to use for the following situations:
This essentially has the effect of issuing a SQL UPDATE statement using the WHERE clause that constrains the foundset. This presents a significant performance advantage over updating records individually. In the example below, a related foundset is updated, meaning all orders belonging to the selected customer will be affected. Please note: This method will not trigger any associated Table Events or modification columns.
The Foundset Updater API can also be used to update part of a foundset. Moreover, unlike the above example, this approach allows for different values for each record. In the example below, the first 4 records (starting from the selected index) are updated by specifying an array of values for each column that is affected.
When using this approach, it matters what the selected index of the foundset is. The update will start with this record.