Features of Athena Framework

As a solid ORM framework with built-in support for cloud applications, Athena offers many other distinguished features.

Metadata as the Single Source of Truth

In Athena, metadata refers to the collection of all entities, attributes and relationships in database modeling for the application. Any change made on metadata reflects immediately in the database schema and domain object classes. For example, when you add a new attribute named fullName to entity Employee, a new column will be automatically inserted to the corresponding table in the database and a new field will be available in the Employee's domain class when you generate the source code. Architectures of traditional XML/Java annotation based ORM frameworks and Athena are compared below:

Implementing Change at the Speed of Your Thought

Athena realizes true rapid application development by allowing developers to implement changes easily and quickly. Let's say, we need to change Person.fullName's type from CHAR(100) to NVARCHAR(256). For those who use traditional ORM frameworks, they need to manually change database table's column type and to update XML or Java annotation mapping configuration, and updates the UI validation code. Such steps are time-consuming and error prone. Athena comes to rescue: you only need to change the attribute type and save it on the user friendly Athena Metadata Workbench. Athena automatically update the database schema and generate updated source code. Developers' productivity gets significant boost by Athena.

Gaining Total Control of EJBQL Querying

When performing EJBQL queries in Athena, you do not need to guess which relationships will be loaded and which will not be loaded. Instead, you can specify explicitly which relationships will be loaded and how they should be loaded. For example, the query below selects Employees with relationships of department and projects:

SELECT e FROM Employee e [e.department:J, e.projects:S]

The relationship prefetch rules in the square brackets specify that relationship department shall be resolved through join while projects through sub-select query.

Fine-Grained Query Specific Partial Attribute Loading

Some other ORM frameworks allow the developer to specify the fetch policy for an attribute. Athena allows queries instead of the attribute to control the loading behavior. In Athena, you may explicitly specify attributes to be loaded for partial objects:

SELECT e FROM Employee e {po_e='nameFull, bornYear'} -- Load partial object with two attributes only

Developing Multi-Tenancy Cloud SaaS Applications With Ease

A multi-tenancy application enable a single instance of the software runs on a server, serving multiple client organizations (tenants). Athena allows you to easily develop shared schema multi-tenancy applications like salesforce.com. To turn an application to multi-tenancy, you simply set the multitenancy flag in the configuration file. For example, EJBQL SELECT e FROM Employee e LEFT JOIN FETCH e.dept results the following native SQLs when multitenancy is true and false respectively:

SELECT e.employee_ID, e.fullName, e.department_ID, d.department_ID, d.nameFull FROM Employee e LEFT OUTER JOIN Department d ON e.department_ID = d.department_ID
SELECT e.employee_ID, SELECT e.employee_ID, e.ORG_ID, e.fullName, e.department_ID, d.department_ID, d.ORG_ID, d.nameFull FROM Employee e LEFT OUTER JOIN Department d ON e.department_ID = d.department_ID AND d.ORG_ID = 1 WHERE e.ORG_ID = 1

As Athena handles multi-tenancy automatically, you can foucs on implementing business logic.

Switching Between Soft Deletion and Hard Deletion Quickly

Soft deletion is one of the key requirements for many enterprise applications to ensure data integrity and auditing. Athena allows you to switch between soft deletion and hard deletion quickly using the deletion-policy option in the configuration. By default, hard deletion is used. To switch to soft deletion, you simply set deletion policy to soft.

The Ultimate Solution to Database Versioning and Migration

Database migration is heavily involved in development, testing and product upgrading. For example, when you help a customer to upgrade a product from version 1 to version 2, you need to update the jar files as well as the database schema. It's usually required that all existing data should be preserved when the database shema gets updated. It implies that you need to keep track of all code changes as well database schema changes. Normally, you use a revision control system such as Subversion to version code changes. As for database schema changes, many developers use migration scripts to manually version the changes, for example, 001_db_init.sql, 002_emp_table_added.sql, 003_emp_field_name_changed.sql, etc. To migrate a database schema from version M to version N, you simply apply all scripts between M+1 to N.

Using the same idea behind database migration scripts, Athena stores all incremental changes (delta script) to the database schema in the table unmanaged_dsc. When you use metadata workbench to make changes, database migration scripts are stored in the table automatically. This automated process significantly reduces the complexity of database versioning and migration.

For details, please review list of features of Athena.