Tuesday, November 22, 2011

Executing multiline SQL statements with G operators

Little that we really want to do with SQL databases is done on one statement, so we need a series of statements and tie them to a single operator. In G, version 1.x, the standard method is to issue a series of direct SQL stateents with the G_SQL operator. Then tie the operator to a call to the start of the sequence. G will run the sequence and return the machine properly.

I can set up series of sql statement in my M4 processor, as part of the install. In M4 it looks like:

START(MyProc);
SQL(`delete from result;');
SQL(`insert into result select * from other;');
SQL(`select key from result where self.key == result.key;');
END;
INSTALL(Operand,MyProc);


These generate the proper inputs fer sqlite to load them to config in triple format. As long as the install stays in the config triple store, this should work. The START macro define the starting row of the procedure. The END macro makes sure the procedure ends with the exit triple, forcing a return. Whenever I need the procedure, I deliver a triple G_CALL to the row. Nesting shouldn't be a problem, the call to the triple machine is re-entrant (or will be soon!!) and G automatically lets the c compiler manage stacking. In G the select output is delivered to the command line. Installing and configuring G is not something we need to be interactive right away, so the M4 does a fine job.

Let's say we had a list of triple stores that needed searching, and we have an operator set up. Then in TE we have:

(G1.G2.G3...) @ _OPS:Oper

Here, the Gi refer to conformal subgraphs. The _ operator tells me this is linked to the local Gm achine. The OPS schema tells me to look in the operator list and execute. The operator will re-execute on each of the subraphs Gi. There is no reason to make the Gi conformal, only that the operator understand their format. The parenthesis around the list Gi is unnecessary because the convolution operator @ is lightweight. It will not distribute over any set operators, nor will it commute with any descent operators.

No comments: