Query processing

As it was stated before, the Preprocessor analyzes the query in order to check whether it involves any Jelly Views. The query is sent using SQL syntax. A straightforward analysis would be parsing the given query using the SQL grammar. Having the External Matching, the query can be checked whether it addresses a Jelly View or not.

Unfortunately, there is a problem with the SQL grammar itself. As it was mentioned before (see Section 2.1), most of the database systems these days, conform to some subset of the SQL standard only. There is no uniform SQL understandable for all the databases. The differences among SQL dialect could be cosmetic or more serious. Some keywords required by the standard may be not mandatory for some databases. Some standard complying queries may be not accepted at all (when a database implements only part of the standard), while the other queries, not covered by the standard, may be perfectly legal (for example object oriented extensions or handling of LOB: Large Objects).

ODBC does not solve this problem. It provides the communication protocol and it does not analyze a query. It forwards it from the application to the driver.

Figure 10.4: Detecting Jelly Views, the FSM Diagram

Table 10.1: Detecting Jelly Views, the FSM transitions

Transition	Description
ID	an identifier which begins with a letter or an underscore and consists of letters, digits or an underscore
LP	open parentheses: '('
RP	close parentheses: ')'
COMMA	a comma: ','
QSTRING	a string of any characters bounded by single quotes

The syntax of the query cannot be verified and there is no complete SQL grammar. The only certain thing is that there could be a reference to a Jelly View which has the syntax of SQL function, which is:

  function_name( parameters )

where parameters is a comma separated list of parameters passed to the function. A finite state machine (FSM) can be used to detect any appearance of such a function in the query. The FSM diagram is given in Figure 10.4.

Initially, the machine is in the state number 0. It accepts the expression if it is in the state number 5. If the input (a token) does not match a transition, then the machine is reset to the initial state. The explanation of the transition labels are given in Table 10.1.

If there is an expression in the query which is accepted by the FSM, and its name and the number of arguments match the information provided by the External Matching, then this is a reference to the Jelly View.

The Preprocessor follows the following algorithm:

1. tokenize the query,
2. apply the FSM to the tokens,
3. if the FSM accepts the expression (it is in the state number 5), check whether it complies with the External Matching in terms of the name of the Jelly View and its arity,
4. if there is a match, then the expression is altered (as a result the query is rewritten),
   1. if there has been a Jelly View with the same name and the same values of arguments before in the query, then its name is used instead of the expression,
   2. if there has been a Jelly View with the same name, but with different values of arguments, then a Jelly View Alias is created; the alias is just the Jelly View name with a number added at the end; the number indicates that this is a reference to a Jelly View which has already been used in this query; however, it has different arguments, so it may have different state (contents),
5. if there is no match, then go to 2.

As a result the original query is rewritten. All references to Jelly Views are replaced with their names or aliases. There is an example query below:

  SELECT * 
  FROM jelly(1,) AS j1, 
       jelly(,3) AS j2, 
       jelly(1,) AS j3, 
       other_jelly() AS j4
  ;

The assumption is, that there are registered Jelly Views, which are referred to as relations jelly and other_jelly; jelly has two attributes, other_jelly has one attribute. The statement: jelly(1,) passes 1 as the first argument and leaves the second argument unbounded. It means that all tuples of j1 will have 1 as the value of the first attribute and the value of the second attribute will be inferred. Similarly, the first argument is unbounded and the second is equal 3 for j2. Analogically j3 and j4.

The query above is rewritten as:

  SELECT * 
  FROM jelly AS j1, 
       jelly1 AS j2, 
       jelly AS j3, 
       other_jelly AS j4
  ;

The relation jelly will hold data generated by a goal associated with the relation jelly, which has two attributes and there is one argument (1) passed to the goal. It means, that the relation will hold rows with the value of the first attribute fixed at 1 and a value of the second attribute inferred by ReDaReS.

The relation jelly1 is an alias. It will hold data generated by the goal associated with the relation jelly. There is a single argument passed to this goal which is 3. jelly1 is an alias because jelly has already been used in the query, but this time different arguments are passed to the goal, so the state of such generated view will be different than the previous one. Both states, for this and the previous view, are generated by the same goal, logic program and matchings. The relation jelly1 will hold rows which have the value of the second attribute fixed at 3, and a value of the first attribute inferred by the inference engine.

The relation other_jelly will hold data generated by a goal associated with the relation other_jelly, which has only one attribute. There is no argument passed to the goal, and the contents, which is a single column,of other_jelly will be inferred by ReDaReS.

The state of these relations will be generated by the inference engine, before the rewritten query is passed to the database. In summary, the preprocessor replaces every reference to a Jelly View with a relation name which will be used to hold inferred data. The inference data is generated by the inference engine, the goals for each Jelly View are specified by the External Matching, and the arguments which are specified by the users are passed as the goal arguments.

If there is more than one reference to the same Jelly View with the same arguments, then the same relation will be used. If there is more than one reference to the same Jelly View with different arguments, then there will be different relations created, however they will share the same Logic Program and Matchings. In this case the relations states will differ because of the different arguments passed to the goal.