Servoy's "Data Providers" are the atomic units of the data binding layer. A Data Provider holds an individual data value which may be bound to both User Interface elements, as well as back-end resources. Thus, Data Providers are the link between the user experience and the raw data.
There are several types of Data Providers, each with different data bindings and uses:
Once established, a data provider can be bound to user interface elements at design-time. At run-time, the elements come alive with data which is contextual to the application state and the Data Provider's back-end bindings. The most obvious example is a text field which is bound to a column in the database table. However, any of the types of Data Providers can be bound to any UI components, including fields, labels, buttons, tooltips, etc.
Database Columns are the most common type of Data Provider in Servoy. When a named server connection is established, the entire database structure - all tables and their columns - is read. Columns become available vehicles for data binding. Additional metadata properties are used to further describe how each column is treated in the application.
These properties include:
This is the name that is returned by the JDBC Driver. The name will always be displayed as lower case. The column name is also used as the Data Provider ID when working with foundsets and records.
While relation databases support many different data types, Servoy will generalize the data type of a column into one of five general types. In this way, Servoy can support a wide range of database vendors. The five generalized data types include the following:
For certain data types, databases must enforce the amount of storage allocated to single column for a single record. Data types which accommodate variable length entries, such as text, decimal numbers and binary data will have a length property. Servoy will infer and display this property in the column definition.
Servoy is designed to work with regular database tables as well as SQL Views. Regular database tables will have a primary key, consisting of one or more columns, who's value uniquely identifies a record in the table. Servoy will infer the primary key from the database table. However, in the case of SQL Views, which don't have a built-in primary key, the developer must specify which column(s) can be considered the unique row identifier.
Relational database tables may enforce non-null constraints on certain columns, typically for primary key and other essential columns. Servoy will infer from any such constraints from database table and reflect
Column definitions include several metadata properties, which store information that is used both in development and at runtime.
The Title property of a column is simply the human-readable name for a column. When a field is placed on a form with the Place with labels option, the label's text property will be initialized to the title property for the column to reach the field is bound. For multilingual applications, it is ideal to populate a column's title property with an i18n message key, thus allowing field labels to default to message key, which is translated at runtime.
The Default Format property of a column will enforce the formatting that is used when the column is bound to a field element. The field element's format property will assume the default format of the column unless it is overridden in the element.
This is a simple metadata property to indicate that a column is a foreign key to another table in the same database. One can set the Foreign Type property to the target table. This provides metadata so developers will know that a column is used as a foreign key. Servoy will use this information when new relations are created between the tables and auto-fill the keys. This property is also used by the mergeRecords method of the databaseManager API to update any affected related records, such that they'll reference a new key.
Enabling a column's Excluded Flag will completely exclude a column from the Servoy runtime environment. This means that Servoy will exclude this column for every query that it issues. This option is ideal to enforce that certain columns are never available in a Servoy application.
Servoy supports the use of Universally Unique Identifiers (UUID). A UUID is a 16-byte number which can be (practically) guaranteed to be unique across computing environments, making it ideal to use for sequences in scenarios where traditional numeric sequences are not adequate, for example when syncing data which is generated offline. It is generally not feasible to store UUIDs as numeric data types because the number is so large. Rather UUIDs are most easily stored as 36-character strings. When using a text column to store UUIDs, one should mark the column's UUID flag. Thus, Servoy will provide programmatic access to this column in the form of a built-in UUID data type, which allows both string and byte representation.
A column's description property is a simple container for additional metadata, such as programmer notes about the column's purpose, etc.
Servoy provides several ways in which a column may be automatically populated when a record is created. Some of the auto-enter options are also applicable when an existing record is updated.
Indicates that the value is deferred to the database at the time of insert. The value is populated and controlled by the database and it will not be overwritten from Servoy.
The UID parameter that was supplied at the time of login, entered at the time of record creation.
The UID parameter that was supplied at the time of [login|https://wiki.servoy.com:8443/display/DOCS/Security#Security-login|Link to login method in reference guide], reentered each time the record is modified.
The current date and time on the client, entered at the time of record creation.
The current date and time on the application server, entered at the time of record creation.
The current date and time on the client, reentered each time the record is modified.
The current date and time on the application server, reentered each time the record is modified.
A custom value is simply a literal value (i.e. 'Blue', 1.5) which may be used as a default. This option is only available for Integer, Number and Text data types.
This indicates that the value is deferred to the database at the time of insert. However, unlike Database-Managed system values, this value can be modified from Servoy after the record is inserted.
Lookup Values provide the option to auto-enter a value that is contextual to the record being inserted. Options include any of the record's data providers, any data providers from foundsets related to the record, as well as an global relations or variables.
Sequences may be used to auto-increment a column's value. This is ideal for populating primary key columns, which must be unique.
This is a sequence which is defined in the application tier and managed by Servoy. The sequence will generate integer values using a given next value and step value.
In deployment, Servoy Sequences are stored in the repository database and there are options to recalculate the sequence's next value from existing data.
Servoy will call a named sequence in the database to populate the value. The column will be populated and available prior to inserting the record
The sequential values are managed and populated by the database. The column is not populated until after the record is inserted
Servoy will automatically populate a text column with a textual representation of a UUID. Be sure that the column's UUID Flag is also enabled.
Just like real database columns, calculations may be placed as fields on forms, used in data labels, and requested programmatically.
An aggregation is a data provider which represents a database column that is aggregated over a set of records. At design-time aggregations have the following properties:
At runtime, aggregations are computed in the context of a foundset. The value is derived from a SQL query, which takes the form of a SQL Aggregate Function and appends the WHERE clause used by the foundset's query.
Variables are Data Providers which, unlike columns, calculations aggregations do not bind to any persistent, back-end data source. Instead, variables store data in-memory for the duration of the client session only. However, variables may bind to UI components the same as any other data provider.
Notice that these are the same as the generalized data types for column-based Data Providers.
Variables can belong to one of two scopes:
Other than programming scope, the only difference between the two is that globals can be used as keys in relations.