Skip to content

Rave Tables and Data Lookups (etables)

In previous examples, we hardcoded constants like %max_flight_time% = 09:00. In a production airline environment, you almost never hardcode business values.

Airlines have thousands of parameters: meal allowances that change by country, maximum duty times that vary by the number of sectors and the time of day, and seniority pay rates. These are stored in proprietary tabular databases called etables (Evaluation Tables).

1. The Structure of an etable

An etable is essentially a CSV or relational database table injected into the Jeppesen environment.

Example Table: max_duty_time.etab

Sectors Is_Night_Flight Max_Duty_Time
1 False 14:00
2 False 13:00
3 False 12:00
1 True 11:00
2 True 10:00

2. Querying Tables in Rave

Rave provides built-in syntax to query these tables dynamically during search tree traversal.

// 1. Define the search keys
%sector_count% = count(leg(duty));
%is_night% = duty.%starts_in_wocl%;

// 2. Perform the table lookup
// syntax: table("table_name").lookup(key1, key2, return_column)
%dynamic_max_duty% = 
  table("max_duty_time").lookup(%sector_count%, %is_night%, "Max_Duty_Time");

// 3. Apply the dynamic constraint
CONSTRAINT dynamic_max_duty_check OF Duty
  COMMENT: "Duty time must respect the dynamic etable limits."
  STATUS: ON;
  RULE:
    duty.%elapsed_time% <= %dynamic_max_duty%;
ENDCONSTRAINT

3. Why etables Matter

By externalizing the parameters into etables, the airline achieves Configuration over Code.

  • If the pilot union negotiates a new maximum duty time, the airline's operations staff can simply update the etable via a user interface.
  • The Rave Developer does not need to rewrite, recompile, and redeploy the core Rave codebase. The compiled rules automatically fetch the new data at runtime.