Concepts

Overview

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.

Database Connectivity

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:

Query Engine

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.

Named Connections

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 Databases for more information. See Database Server Connection Editor for more information.

Switching Connections

Servoy allows applications to switch 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

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 pool of database connections for each Server Name, ensuring efficient use of database resources and reducing the latency associated with establishing new connections.

Data Binding

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:

Dynamic Data Binding

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.

Client Cache

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.

Data Broadcasting

When a record is inserted, updated, or deleted by any Servoy client, the Servoy Application Server broadcasts a Data Broadcast 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.

Updating the Client Cache

Client caches may become "stale" if data changes outside of Servoy client sessions. Servoy provides several APIs to update client caches programmatically:

• Flush All Client Caches: Refreshes all records in all client caches for a specified database table, ideal after significant external changes.

• Notify Data Change: Sends a data broadcast event for specific records, useful for targeted updates.

• Refresh Record from Database: Refreshes the cache for a single record or entire foundset in the calling client, ideal for localized changes.

Data Operations

Data manipulations 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.

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:

Auto Save: ON

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.

Auto Save: OFF

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.

The Anatomy of the In-Memory Transaction

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.

Saving Data Changes

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.

Rolling Back Data Changes

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.

Deleting Records

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 Foundset

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:

Forms Bound to a Foundset

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.

Shared Foundsets

Forms bound to the same table share the same foundset, providing a unified view of data across different forms.

Named Foundsets

Developers can create named foundsets for specific scenarios where forms need different subsets of the same data table.

Loading Records

Records can be loaded into a foundset in various ways:

• Load by Single PK: Load a record by its primary key.

• Load by PK Data Set: Load records based on specified primary key data.

• Load by Another Foundset: Copy the query of another foundset.

• Load by Query: QBSelect: Use a query builder object to set the foundset's query.

• Load by Query: SQL String: Use a SQL query fragment to set the foundset's query.

This flexibility allows developers to meet specific application needs efficiently.

Sorting

Foundsets can be sorted programmatically using SQL-like syntax to present data in the desired order.

Scrolling Result Set

Scrolling result sets handle large datasets efficiently by loading data incrementally as needed.

Iterating Over a Foundset

Developers can iterate over records in a foundset using standard loop constructs for batch operations or complex data manipulations.

Foundsets and Data Broadcasting

Changes to data in one part of the application are automatically propagated to all parts using the same foundset, ensuring data consistency.

Related Foundsets

Related foundsets manage related data across different tables, leveraging defined relationships to navigate and manipulate related records.

Performing Batch Updates

Batch updates allow developers to apply changes to multiple records in a single operation, improving performance and ensuring consistency.

See JSFoundSetUpdater for more information.