The SQL-wildcats % and _ are recognized as simple characters in UQL, which makes the ESCAPE literal token obsolete. In the following, the UQL tokens are listed in tables.
----------------------------------------------------------------------------
Token Description
----------------------------------------------------------------------------
AVG Average function
MIN Minimum function
MAX Maximum function
SUM Summation
COUNT Number of entries found
FROM Specifies a list of class names
IS Keyword
NOT Negation
NULL Value of and attribute which is not available
AND Logical AND operation
OR Logical OR operation
SELECT Keyword for an UQL select_statement
WHERE Keyword for the where_clause in an UQL select statement
SHOW Reflection function
TABLES Reflection subject is a list of tables
ATTRIBUTES Reflection subject is a list of attributes
COMMANDS Reflection subject is a list of commands
UPDATE Keyword for the UQL update function on attributes values
SET Keyword for the UQL set function on attribute values
* Allquantor
------------------------------------------------------------------------------
Table 1: Literal keyword tokens
The following operators in Table 2 can be used within UQL statements to compare attributes and values.
----------------------------------------------------------------------------
Token Description
----------------------------------------------------------------------------
= Equal operator
<> Different operator
< Inferior operator
> Superior operator
<= Inferior or equal operator
>= Superior or equal operator
----------------------------------------------------------------------------
Table 2: UQL defined operators
Additionally, Table 3 defines mathematical operators. The star is used as a wildcard. Opposed to SQL the single dot is not needed as a column separator, but remains valid as a numerical separator. The comma is used for lists of attributes. Brackets assign precedence.
----------------------------------------------------------------------------
Token Description
----------------------------------------------------------------------------
= Equal operator
+ Plus operator
- Minus operator or sign
* Multiplication operator
/ Division operator
() Precedence
, Separator between tables and attributes
Numerical Separator
----------------------------------------------------------------------------
Table 3: UQL defined operators
In the following two tables, the names and number types are represented by regular expressions.
----------------------------------------------------------------------------
Token Description
----------------------------------------------------------------------------
[A-Za-z][A-Za-z0-9_]* A NAME token does not start with a number
and has at least one letter.
----------------------------------------------------------------------------
Table 4: UQL NAME token
The UQL number tokens in Table 5 are SQL compliant. Examples for INTNUM numbers are: 42 or 1.23 or .04. Examples for FLOATNUM numbers are: 4e-5 or 1.23E-2 or .04e2.
----------------------------------------------------------------------------
Token Description
----------------------------------------------------------------------------
[0-9]+ |
[0-9]+"."[0-9]* |
"."[0-9]* The value of an INTNUM token is
either a plain integer number or
a decimal value or only the
decimal places of that number.
[0-9]+[eE][+-]?[0-9]+ |
[0-9]+"."[0-9]*[eE][+-]?[0-9]+ |
"."[0-9]*[eE][+-]?[0-9]+ The value of a FLOATNUM token is
either a plain integer or a decimal
value or the decimal places of that
number only.
----------------------------------------------------------------------------
Table 5: UQL number tokens
Strings in SQL and UQL are enclosed in single quotes, using a pair of quotes to represent a single quote in a string. Strings cannot span over multiple lines. The lexer appends two directly adjacent quotes.
----------------------------------------------------------------------------
Token[1] Description
----------------------------------------------------------------------------
'[^'0*' A valid UQL STRING token
'[^'0*$ Unterminated string token. The parsing is aborted.
----------------------------------------------------------------------------
[1] Some regular expression syntax:
[^,] means any character, which is not a comma.
[^,]* means 0 or more characters, which are not commas.
$ matches the end of line.
Table 6: UQL STRING tokens
The End-Of-Line tags and white spaces are ignored. The same for comments introduced with two dashes. Line numbers can be counted for error messaging. Table 7 lists these void tokens.
----------------------------------------------------------------------------
Token Description
----------------------------------------------------------------------------
\n Increases the counter for line numbers in the lexer, but
does not forward a recognized token to the parser.
[\t\r]+ Recognized white spaces do not forwarded any token to
the parser.
"--".*$ Recognized comments do not forward any token to the parser.
----------------------------------------------------------------------------
Table 7: UQL void tokens
This subsection presents the UQL grammar. The syntax of the following grammar specification follows the Backus Naur Form (BNF) as used for YACC grammar specifications. The prefix opt_ in a clause-name indicates optional parts. The UQL uses a SELECT statement, which uses a subset of the quite complex grammar from the SQL select statement. For instance, it does not support sub-queries, joins, having, group-by clauses, or temporary variables. By the means of a selection, the UQL query specifies the set of attributes of interest, including the usage of the allquantor *. The from_clause consist of a unique class id. For instance, the ULLA_Link class, which is the allquantor for all available link class entries.
In the following
CAPITAL wording indicated tokens from forwarded from the lexer.
uql_list: uql ';'
uql: select_statement
| show_statement
| update_statement
select_statement:
SELECT select_clause
FROM from_clause
opt_where_clause
SEMICOLON
There are two different types of a select_clause: The first option is that it contains a FUNCTION, which can be used for post-processing on the result of the query. However, the post-processing can be performed only on an attribute_list of a single attribute, which is not checked by the parser but by the implementation of the ULLA Core. The second option is that it is composed of a list of attribute references.
select_clause:
selection
selection:
attribute_list
| '*'
| ammsc ( attribute_list )
| ammsc ( '*' )
ammsc: AVG
| MAX
| MIN
| SUM
| COUNT
attribute_list:
attribute_ref ',' attribute_list
| attribute_ref
The update_statement is used to update attribute values. It has the
update_clause listing the repective tables and the set_clause setting new
values to particular attributes.
update_statement:
update_clause
set_clause
opt_where_clause
SEMICOLON
update_clause:
UPDATE tables
set_clause:
SET set_list
set_list: set_list ',' set_predicate
| set_predicate
set_predicate:
attribute_ref EQUAL const_ref
The final statement is part of the reflection interface. The show_statement
is used for the retrieval of a list of available tables. Also, for each
table a list of attributes and commands can be queried.
show_statement:
show_tables
SEMICOLON
| show_reflection
from_clause
SEMICOLON
show_reflection:
SHOW reflection
show_tables:
SHOW tables
reflection:
| ATTRIBUTES
| COMMANDS
Attribute references can be used for simple or joined queries. If using
a simple attribute reference the single table indicated in the from_clause
will be as a basis for the attribute lookup. If using joined-queries the
table name may be specified for each table individually. A list of all
used table names then needs to be put to the from_clause.
attribute_ref: attribute
| table '.' attribute
attribute: NAME
The from_clause of the select_statement reduces pretty simple to a list
of comma-seperated names, indicating the tables containing the selected
attributes. In simple queries there is only a single class name. Joined
queries may have multiple names.
from_clause: tables
tables: table_list
table_list: table_ref
| table_list ',' table_ref
table_ref: table
table: NAME
The UQL uses the opt_where_clause to make the where clause optional. The
where clause consists of a condition to further specify the set of relevant
links.
opt_where_clause: /* empty */
| WHERE search_condition
The UQL search condition can be almost as complex as in SQL. Logical concatenation
can be done with AND and OR, negation with NOT, and precedence can be set
by the means of brackets. Further refinements with predicates allows for
attribute conditions based on simple comparisons, range specifications
with between, similarity recognition with like, null-testing, and comparison
with well-defined sets with in.
search_condition:
predicate OR search_condition
| predicate_AND search_condition
| NOT search_condition
| '(' search_condition ')'
| predicate
predicate:
comparison_predicate
| test_for_null
comparison_predicate
scalar_exp comparison scalar_exp
test_for_null:
attribute IS NOT NULLX
| attribute IS NULLX
The basic blocks of this grammar are scalar expressions, which represent
a companionable part if the attribute values are available. However, in
a first step the parsing might result in a binary tree with nodes carrying
the query-blocks and no computed results yet. The signs - and + have precedence
when reducing a scalar expression.
scalar_exp:
scalar_exp '+' scalar_exp
| scalar_exp '-' scalar_exp
| scalar_exp '*' scalar_exp
| scalar_exp '/' scalar_exp
| '+' scalar_exp %prec UMINUS
| '-' scalar_exp %prec UMINUS
| '(' scalar_exp ')'
| literal
| attribute
The UQL-specific SYSDATA function is captioned as a new function_ref element
of the grammar to be used in a selection statement. Opposed to SQL, the
table consists of a single string without any separated sub-tables, such
as name.name. The same applies for the attribute reference, because attributes
in the link classes cannot have sub-attributes and no temporary variables
can be specified, which would require this notation.
literal:
STRING
| INTNUM
| FLOATNUM
comparison :
EQUAL
| DIFFERENT
| INFERIOR
| SUPERIOR
| INFERIOR_OR_EQUAL
| SUPERIOR_OR_EQUAL
The LLA can define multiple classes and map attribute to each
of them. These classes are presented as tables via the UQL. For instance,
an LLA for a WLAN device driver would support all attributes of the ullaLink
class, which always has to be supported. Additionally, it registers classes
such as p80211Link, and ieee80221Link. These classes support additional
attributes in order to provide a more specific inside to the technology
in use.
In order to read attributes from multiples classes within a single query,
joined-queries may be utilized.
Class names get be read via the reflection interfaces: cat /proc/net/ulla/reflection.xml
cat /proc/net/ulla/reflection.dtd
The following examples give a quick overview of the usage possibilites
of the UQL for accessing attributes from various classes. All UQL statement
are valid UQL statements, but not all fit with the class model in use.
---------- ------------ ---------------
| ullaLink | | p80211Link | | ieee80221Link |
---------- ------------ ---------------
-------------------------------------------------------------------------
UQL statement Valid query?
-------------------------------------------------------------------------
SELECT rxBandwidth YES, because the attribute is
FROM ullaLink; defined as part of the class
description.
SELECT rxBandwidth, linkId YES, because both attributes
FROM ullaLink; are defined as part of the
class description. This is a
simple query.
SELECT ullaLink.rxBandwidth YES, because joined-queries
FROM ullaLink; may use only a single table
name, too.
SELECT SNIR YES, because the attribute is
FROM p80211Link; defined as part of the class
description.
SELECT SNIR NO, because the attribute is
FROM ullaLink; not part of the class
description.
SELECT p80211Link.SNIR, ullaLink.linkId YES, because joined-queries
FROM ullaLink, p80211Link; can span over multiple tables.
SELECT SNIR, linkId NO, misbuild joined-query.
FROM ullaLink, p80211Link;
SELECT p80211Link.SNIR, linkId NO, misbuild joined-query.
FROM ullaLink;
-------------------------------------------------------------------------
The LLA will register a new link to the ullaLink class if a new peer is visible via the card in use.
This ULLA implementation supports composition and aggregated links to show inter-dependencies: Each link has an attribute parentId. If the parentId is set, this link is a physical link. If the parentId is equal to the linkId there is no associated aggregated link. Otherwise the parentId indicates the associated aggregated Link by its linkId.