Concepts
Last updated
Was this helpful?
Last updated
Was this helpful?
Servoy provides a robust and flexible platform for handling data within business applications. This chapter introduces the key concepts for understanding how Servoy manages data and how developers can interact with it effectively.
At its core, Servoy is a comprehensive platform for developing database-driven applications. Servoy allows developers to connect to any standard Relational Database Management System (RDBMS) using Java Database Connectivity (JDBC) technology. JDBC is a connectivity standard that allows Java-based applications to interact transparently with any database vendor that provides a compliant driver.
Key Points:
The Servoy platform uses Structured Query Language (SQL) to issue requests to databases. While traditional database application development requires advanced SQL knowledge, Servoy dynamically generates all the SQL required to read and write data, optimizing queries and ensuring database neutrality. Developers can still write their own SQL for complex scenarios if desired. This capability provides flexibility while ensuring efficiency and portability.
Developers specify a Server Name that maps to a specific database connection configuration, including user credentials and database URLs. At runtime, Servoy creates a pool of connections for the given Server Name, which are reused for the duration of the application server uptime. This insulates developers from the complexities of database connections and improves application performance by reducing the overhead associated with creating and closing database connections.
See for more information. See Database Server Connection Editor for more information.
Servoy allows applications to between different database connections programmatically. This is particularly useful in multi-tenant applications where each tenant might have their own database, or in scenarios where different types of data are stored in different databases.
Connection pooling is a technique used to maintain a cache of database connections that can be reused, improving performance and resource utilization. Servoy manages a of database connections for each Server Name, ensuring efficient use of database resources and reducing the latency associated with establishing new connections.
Data binding in Servoy refers to the association between the user interface (UI) components and the underlying data models. This concept allows for seamless synchronization between the UI and the data, ensuring that any changes in the data are automatically reflected in the UI and vice versa.
Key Points:
Servoy provides both a Graphical User Interface (GUI) and an Application Program Interface (API) that dynamically bind to database resources. The Servoy Application Server dynamically generates and issues the SQL required to read, insert, update, and delete database records in response to user actions and developer instructions.
Example: When a user navigates to a form bound to a database table, the Servoy Application Server issues a SQL select statement to retrieve and display the data. If a user modifies a value in a text field and clicks out, the server issues a SQL update command to save the changes, broadcasting them to other connected clients.
Servoy clients maintain a cache of database records to optimize performance. This client cache keeps track of records in use by primary key, reducing the number of database queries. Cached records are automatically updated or reloaded as needed, enhancing user experience by allowing quick navigation and data access.
Client caches may become "stale" if data changes outside of Servoy client sessions. Servoy provides several APIs to update client caches programmatically:
Data operations in Servoy refer to in-memory transactions and should not be confused with database transactions. These in-memory transactions track changes made to data before they are committed to the database.
Key Points:
By default, every Servoy client starts with Auto Save set to on/true. This means changes are committed automatically as the user navigates the client session. Specific actions, like clicking in a form's area, navigating to a different form, or clicking a button, trigger a save event.
When Auto Save is set to off/false, the length of the in-memory transaction is controlled by the developer. Changes are not committed until the developer programmatically invokes a save event. This is ideal for scenarios where a group of edits may be saved or rolled back together.
Servoy provides a data API that tracks all added or modified records and their changed columns, including former and latter values. This allows developers to distinguish between new records not yet in the database and existing records with pending edits.
A developer can programmatically issue a save event to commit the in-memory transaction to the database. This can be done for all changes or for specific records. If any records cannot be saved due to errors, these are tracked separately.
A developer can issue a rollback command to revert all changes in the in-memory transaction. Alternatively, rollbacks can be applied to specific records, leaving the rest of the transaction unaffected.
Record deletions are not part of the in-memory transaction. When a record is deleted, the instruction is sent to the database immediately and cannot be rolled back.
The Servoy Foundset is a key component in Servoy's data binding layer. A foundset maps to a single database table (or view) and manages reading and writing data to that table. It controls which records are loaded, displayed, created, edited, and deleted.
Key Points:
A Servoy Form is bound to a single database table and contains a single foundset bound to that table. Actions in the UI, such as editing data fields, affect the form's foundset, and vice versa.
Forms bound to the same table share the same foundset, providing a unified view of data across different forms.
Developers can create named foundsets for specific scenarios where forms need different subsets of the same data table.
This flexibility allows developers to meet specific application needs efficiently.
Scrolling result sets handle large datasets efficiently by loading data incrementally as needed.
Changes to data in one part of the application are automatically propagated to all parts using the same foundset, ensuring data consistency.
Batch updates allow developers to apply changes to multiple records in a single operation, improving performance and ensuring consistency.
When a record is inserted, updated, or deleted by any Servoy client, the Servoy Application Server broadcasts a event to all clients. This ensures that all clients have a real-time, shared view of the data. Developers can enhance this functionality by implementing the solution's onDataBroadcast event handler.
: Refreshes all records in all client caches for a specified database table, ideal after significant external changes.
: Sends a data broadcast event for specific records, useful for targeted updates.
: Refreshes the cache for a single record or entire foundset in the calling client, ideal for localized changes.
in Servoy happen inside an in-memory transaction. When a record is created or modified, either by user action or by the developer, nothing is committed to the database immediately. The Servoy Client tracks all newly created and modified records, including which columns have changed, and their former and latter values. These changes accrue in the in-memory transaction until they are committed or rolled back.
Records can be into a foundset in various ways:
: Load a record by its primary key.
: Load records based on specified primary key data.
: Copy the query of another foundset.
: Use a query builder object to set the foundset's query.
: Use a SQL query fragment to set the foundset's query.
Foundsets can be programmatically using SQL-like syntax to present data in the desired order.
Developers can over records in a foundset using standard loop constructs for batch operations or complex data manipulations.
Related foundsets manage related data across different tables, leveraging defined to navigate and manipulate related records.
See for more information.