[yaala] Yet another query language

[Макс]

All this time i meditated about how the query directives should look
and work like. I've named it YAQL - kinda yet another query language.
I'll try to write complete and more detailed description later.
Now i want to explain major ideas to discuss.

Main features i want to implement:
- random data expressions, not only simply aggregations;
- random key expressions, not only keyvars from log record;
- assigning variables to reuse expressions;
- localization of allcalculations into select-directives
  out from other modules (i mean TOTAL aggregation, splitting
  timestamps into day/hour, etc);
- input filtering of processed records (like time range);
- output filtering of datapase records (like 'lessthen');
- speicying sorting order;
- specifying data formatting;
- assigning data labels;

Other features in trouble:
- arranging TOTAL aggregation
- making cross references b/wean tables;

Here is semantic of YAQL in object-oriented notations.

Selection {
    /* defines how to calculate data expressions */
    List<Definition> data_definitions;
    /* defines how to lay out them into report tables */
    Aggangement layout;
    }

Definition {
    /* reference to expression, log field or constant */
    Variable data_def;
    /* matching input data to proceed, or to skip evaluation*/
    Expression &input_filter;
    }

Arrangement {
   /* report-module-dependant layout specification */
   List<Grouping> layout;
   /* matchin data to skip into "ignored" row */
   Expression &output_filter;
   /* sorting order */
   List<Variable> sort_order;
   }
Grouping {
   List<Variable> split;
   }

'layout' defines how to split global database table into report tables.
each variable in 'split' reference mainly to some keyvar.

Currently i see up to 4 splittings:
rows/columns/tables/pages
this works like in yaala 0.5.
I added 'pages' splitting to do not put alot of tables on the same page.

Each 'split' may contain list of any keyvar (mainly referenced to log
record fields) or to list of ALL data expressions.

Variable {
   Id name;
   Expression &expr;
   scalar value;
   }
   
A variable references to expressions, but not to value,
because the same expression may give different values in different context
within the same SELECT statement.
(Egg, if variable referenced in definitions with diffferent input
filters)
It is compiler task to optimize variable assignement to avoid recalculations.

Formatting properties applied into derived 'class':

Displayable : Variable {
    String label;   /* label to display in headers */
    TypeId type;    /* type denoting sorting method and fefault format */
    String formatspec; /* some user defined formatting, alignment */
    }

(Any) Expression is defined recursively:
Expression {
    Operator op;
    List<&Expression> arguments;
    }
    
operator may be arythmethic, string, boolean, or whatever operator OR
aggregation function.
Some special operator (empty or '$') should be used to r4eference to
another variable.

I suggest to use these structures as internal (compiled) presentation
of yaql statements.
Following these scheme we may add other features w/out recoding other
modules - they will just ignore unknown properties.

YAQL module should compile select statements into these structures,
associating every expression with "variable".
Other modules (parser, database, report) will then reference to
these variables to access expressions and statements.
Evaluation of expression is (probably) also a task of YAQL module -
database will give it a context (assignements from logrecord) and
request to evaluate necessary variables(expressions), which are then
stored into database pool.

Other modules will definitely have their own internal presentation.
But keeping their interface in accordance of YAQL presentation we
will keep interface generally clean and extensible.

I'll later describe suggexsted syntax of yaql.

-- 
qMax