|
|
|
|
|
|
File notification is an FairCom Database feature providing an ability to receive messages when a record is added, deleted, or updated from a server-controlled data file. A specific benefit of this feature is that, unlike replication, this can be also used with non-transaction controlled files. By default, these messages are inserted into a FIFO queue for asynchronous handling. This method is an extremely flexible design; however, queue processing has potential to fall behind or worse, is not persisted in case of system failure losing queued changes. The File Notification callback allows for immediate synchronous processing of these messages.
The File Notification callback must be compiled directly into the server process using the FairCom Server SDK.
|
|
|
Much like File Notification, Record Update Notification, or Record Update Callbacks (RUCs) triggers events on record updates. Unlike the generalized File Notification feature, however, RUCs persist changes for both transaction and non-transaction files. RUCs are ideally suited for application data types such as Text, XML, and JSON requiring advanced alternative indexing. Asynchronously processing record updates maintains the fastest up-front application performance while deferring the additional alternative processing required.
RUCs implement processing of these persisted queues. Three callback functions can be defined including file open, file close, and the actual record update function. Unlike File Notification callbacks, RUCs can be defined directly by your application and do not require linkage into the server binary.
|
|
|
FairCom provides developers many levels of data filtering for advanced data searching such as conditional indexes and data filters. Conditional expressions are the backbone of complex data filtering. FairCom includes many conditional expressions that can be defined and evaluated at run time. Many provided functions closely follow C language syntax. There are frequently cases where a desired function isn’t available and FairCom provides an ability to implement user-defined conditional expressions. However, there may be advanced cases where this is still not enough.
FairCom further provides a developer-defined callback function to perform additional custom data filtering and conditional index evaluation. Instead of calling c-tree’s internal expression evaluator to analyze criteria, a user-defined function is called, allowing advanced filtering and control with application specific code.
Conditional expression callbacks must be compiled directly into the server process using the FairCom Server SDK.
|
|
|
Generally, indexes are an application's primary method to search and reduce unnecessary record retrievals. However, additional data filtering can add "as needed" criteria on demand. FairCom data filtering is a method to define temporary specific criteria restricting return of only those records meeting these criteria with dynamic conditional expressions. Unlike conditional indexes, these are not a permanent component of the data file.
Extremely fine-tuned application specific data filters can be defined with Data Filter Callbacks. These callbacks can be further “stacked” for evaluation for truly amazing search capability far outperforming even the most optimized relational query optimizations.
Data filter callbacks are implemented with the CTUSER build system and do not require linkage into the server binary with the FairCom Server SDK.
Data Filters - https://docs.faircom.com/doc/ctreeplus/30429.htm
|
|
|
Data Filters provide advanced search capability. However, they are temporary and can be defined and adjusted at application run time. FairCom provides an extension of data filters as permanent ROW-LEVEL filters that persist within the data file. Permanent row-level data filters have an an added advantage that they can provide “lower level” control including user-level security filtering.
For example, consider an application restricting records viewed in a file by user. A select group of users have ability to see all records, while most other users can only view a small subset of records. A row-level filter can be defined to enforce this restriction. Further, row-level filters can be either read or write. An example of a write filter is one that automatically populates a hidden “security” field in a record with who viewed it, when, and at what location.
FairCom low-level filter callbacks must be compiled directly into the server process using the FairCom Server SDK.
|
|
|
The callback for index rebuild, and by extension the compact function, is designed for progress notifications and to implement custom user interfaces for application-specific rebuild utility programs.
The index rebuild callback is implemented in application-side code and does not require the Server SDK.
|
|
|
When a file is first created, applications may wish to always include custom application-specific embedded resources. These resources may need to be additionally checked on open or close for the latest updates. For example, an application may require a particular format for a file based on the application version. This version information can be embedded into the file as a resource and automatically checked on file open.
FairCom provides a set of callback functions in ctuserx.c for this management. These callbacks require a Server SDK to be linked into the server binary.
