## AQL - Future developments

- Optimisation techniques

  1. uncorrelated subqueries

     list all movie titles with an above-average rating

     `select m->Title from m in class Movie where m->Rating > avg(select m->Rating from m in class Movie)`

     The subquery is inside the `avg()` expression is clearly unrelated to the outer main-query, as it generates just one value independent of the outer query. In the current logic of the language it will be evaluated over and over again for every movie that has a `->Rating` value.

     Currently this query has to be optimised by hand into the form:

     `$x := avg(select m->Rating from m in class Movie);
     select m->Title from m in class Movie where m->Rating > $x`

  2. more semantic-sensitivity

     These two queries have the same result :-

     `select p, m
     from p in class person, m in class movie
     where p->Stars_In = m
     select p, p->Stars_in
     from p in class person
     `

     but the first one would take much longer - the query loops over a cartesian product of both classes (Person and Movie), and then then cuts down the result to the tuples for which the where-clause matches.

- Language extensions

  1. more built-in methods

     More built-in string method like:-

     `select m from m in class map where m.substr(1,3) = "Chr"`

     Other string operators could solve problems like the extraction of the first/last name from the `author->Full_name` strings, etc..

  2. definition of methods

     methods are defined upon the default locator, and can later be used on any locator

     `#size := [2]-[1] where [2] > [1] + 30000;
     select x, x.size
     from object("Sequence","AH6")->Subsequence as x
     order by x.size`

     replaces

     `select s, size::s[2]-s[1]
     from object("sequence","LINK_AH10")->subsequence as s
     where s[2] > s[1] + 30000
     order by :size`

     It is questionable, whether such functionality, shouldn't be provided by the underlying database, i.e. the sequence model had a calculated field that is updated when any of the fields that it is based on are updated. This would require the implementation of Constraints and Triggers in ACeDB.

  3. Sorting by expression values

     Currently one can only sort by values that are evaluated as select-fields and included in the results table. In some cases it would be nice to sort by People's age, for instance, but not actually report it.

     It would be very hard to do in one go, as one can only sort tables once their completely filled in, but not as they are made. One approach is transform queries like this

     `select p from p in class person order by yeardiff(p->date_of_birth,today)`

     into

     `@tmp := select p, yeardiff(today,p->date_of_birth)
     from p in class person order by :2;
     select a:1 from a in @tmp`

  4. A data manipulation language (DML)

     It is desirable to be able to use AQL to update the database, and add new data by AQL commands. It'd be nice if that could be close to the way SQL and OQL do additions and updates.

  5. A data definition language (DDL)

     A well-defined format for database creation, schema-definition would take the pain out of writing and verifying the 'models.wrm' file by hand.