The Business Rules Engine

Reference: Glossary


Users in Coda are defined on a per-server basis, and are granted access to applications and data through roles and groups. Each user has a single login, and users can be either real people or "robots," our semi-funny way of saying "other non-human systems." Additionally, users have basic biographical data fields that can be stored for them. This is to make cross-application data sharing easier.


Applications are the basic units of development in Coda. Applications are the container for tables, forms, procedures, roles, permissions, crons, and triggers, and they are what users connect to when they want to do some work. Coda also has several features to help you control application lifecycle and deployment. Each application has three different instances on the CodaServer, called DEV, TEST, and PROD, and each of these has its own database and data structure. As you develop your application on DEV, CodaServer maintains a revision history of all DDL statements you run. When you are ready to deploy to TEST, simply run a PROMOTE command. When testing is complete, PROMOTE to production.


Coda users can be organized into non-exclusive groups. This has several benefits. For one, access to applications can be controlled on a group basis, so if you are interested in taking a Application Service Provider approach to your apps, this is already built in. Also, tables and forms can be defined with a GROUP flag, automatically segmenting your data for you and ensuring that Company X only sees their own stuff.


Most permissions in Coda are assigned to roles, which are then assigned to users. This is to prevent one-off GRANTS and other access control mischief which can provide forgotten back doors into your data. Roles occur on a per application basis.


Coda was built with a very robust permission system to handle a variety of different models and save application developers from having to "roll their own" with each new application. System and Application Permissions are the only ones which are granted to users directly; all of the rest are assigned to roles, which are then granted to users.

  • Server Permissions: These control what users can do within the CodaServer environment, and include such things as creating users, defining datasources, etc.
  • Application Permissions: These control what users can do with a particular application, such as managing users and managing each of the different environments.
  • User-Defined Permissions: Application developers can define their own permissions and assign them to users. These permissions can then be checked by your application code at runtime to control web page rendering, module access, or anything else.
  • Table Permissions: The typical create, read, update, and delete permissions giving users access to database tables.
  • Form Permissions: These give users access to forms at different points in their lifecycle dictated by form statuses.
  • Procedure Permissions: These give the user the ability to execute stored procedures.


Unlike traditional database systems, Coda is not limited to a few basic datatypes. In addition to the 9 built-in types, Coda lets you specify your own on an per-server basis using Regular Expressions. Each type has a "validation mask" to determine if a given text string is of a valid form, and a "save mask" to format it correctly before inserting it into the database.


Coda is unique amongst database systems in that it doesn't actually store any data itself. Instead, it connects to other industry-standard SQL databases and uses them. Datasources contain all of the information needed to make these connections, such as the hostname and database login credentials. Each application has at least one and up to three datasources assigned to it (one for each environment) and the CodaServer itself has one defined in the coda.conf file that it uses for all of its persistent data.


Coda tables are similar to SQL tables, with the same basic CRUD operations. Tables have columns, each of which has a name and type. In Coda, every table has a primary key column called ID, and has fields for CREATE_USER, CREATE_DATE, MOD_USER, and MOD_DATE. You don't need to define those because they are already there. In addition to regular tables, Coda has three additional table types:

  • Group Tables: The rows of these tables each belong to a particular group, and this is added automatically based on who creates the row.
  • Subtables: Subtables have a parent/child relationship to another table. The classic example is orders and order items. The latter always has a reference to the parent. A table can be both a group table and a subtable.
  • Ref Tables: Ref Tables are tables which are replicated across all application environments on a CodaServer. They are most often used for reference information that needs to be available in every instance, such as "states," "countries," or drop-down box populators. Any inserts, updates, and deletes to one of these tables is automatically reflected in each environment.


Forms are very similar to tables except for one difference: They have statuses.

Statuses are the mechanism Coda uses to maintain form state. Statuses are defined by their relationship to one another. For example, a PLACED order can lead to a SHIPPED order or a BACKORDERED order, or be CANCELED. A BACKORDERED order can later be SHIPPED or CANCELED. Once all of the relationships are mapped out, a form can be moved between them using the Coda language, but can never move out of their predefined sequence. Users have permissions based on the present status of the form.

Just like tables, forms can be Group or Subforms.


Triggers are one of the primary tools the Coda developer uses to maintain data integrity. Triggers can be attached before or after any table CRUD property or form status transition. They can be used to validate data, update related tables, calculate fields, or even stop the operation if particular criteria aren't me.


Procedures are blocks of code that take in parameters and can return data values or resultsets. They are precompiled and run directly within the Coda environment, so they are a fast way to perform operations on your data without incurring network performance penalties.


Indexes provide a way to make queries execute faster by indicating to the server which columns are unique or which tend to occur often in the where clause together.


Crons are scheduled procedure calls. Using a syntax very similar to the Unix "cron" command, recurring events can be registered and executed.