Introduction to Aspect Query Language

In this document we will discuss a new query language called "aspect query language" which allows you to write queries against Transcendental Beans, the aspect oriented database. AQL is similar to other query languages in that it starts with a familiar select style syntax. It has results and condition where clauses. The results from an AQL query can be an instance, a reference to the result, a bean instance derived from the query result, a collection of one of these, or an aspect of one of these results. What does that mean? An aspect can be thought of as data that lives in another dimension, but is united by the AODBMS.

A schema is defined in a variety of ways, the motivations of which are to satisfy different roles of users. For example take the definition of a person:

class Person

String name

String phoneNumber

Suppose that you want an application to monitor who changes the values of a person? You might want to add a field modifiedBy to the Person class. This seems fine for the one application, but what about another application that wants to update another database with changes that come from the person database? This application might need to add a field timeModified to the person class:

   class Person     String name     String phoneNumber     String userId     Date timeModified 

Not Person is getting messy. There are three distinct applications that have contributed to the definition of Person. What about the next application trying to "reuse" person? More fields gett added for every usage context. This becomes a maintenance nightmare, coordinating the other consumers to update their usage and all. An RDBMS can provide seperations for some of these concerns, but isn't a Person supposed to describe things about a person? These fields timeModified and modifiedBy are some sort of metadata about Person, but not really "person" fields.

Maybe a better approach would be to seperate these fields from the domain object of Person, an aspect can be defined that introduces needed fields to support the concern of the aspect, so maybe the Person should look like this:

@ChangeTracked

@Audited

class Person

String name

String phoneNumber

This seems a little better, Person is clean, but it is annotated with these other concerns. Even better would be to support this annotation to a class in the AODBMS DML?

annotate Person ChangeTracked, Audited

Now, all the applications can live without even knowing about each other.

What about getting that data back? AQL can be used to retrieve the metadata from the AODBMS by asking for the aspect in teh result specifier:

select aspect(Audit) from Person where name = 'mike'

returns the userId that modified the definition of person last.