The Plan of Making It

You have read the "Making Of" SMACS

In its simples form the generated callable schema mapping is just an SQL VIEW. However, we do not bother to generated such in the first stage of the project - it is thought to be a degenerate case of normal behavior being more complex. It would be an extension to instlal an optimization step that can see the degenerate case and instruct generation to skip the java glue around the extraction to data insertion making it mere sql select/insert processing.

Instead the first stage of the project is to (a) parse sql (b) split it on selects and insert chains (c) create java loops as foreach record. (d) generate the glue around the loops. That makes it an SQL to SQL/J to JDBC compiler. A thing that makes the execution somewhat less efficient in its first incarnation but at the same time introduces a flexibility not existing in plain SQL.

From there we do not do the next step as for extensions in schema mapping constructs. Instead we extend the system to hold multiple schema mapping rules - the rule base. That rule base might contain parts not written in sql or even generated as "implicit" rules. The rule base will allow us to deploy inter-rule optimizations - possibly interleaving them.

Only after that we inject support for heterogenity - including the schema discrepancies as well as data format mismatches. All these shall be expressed as conditions that trigger a changer execution in the compiler runtime.

Timetable

• jjtree sql parser
• jjtree walker class
• sql view cross ref database and table references
• sql selins cross ref database and table references
• sql view split "select values" result record from conditions
• sql selins split "insert as values" result record from conditions
• generate jdbc glue for connects to databases
• generate jdbc glue for table cursors with given select conditions
• generate jdbc glue for table inserts with given result formatting
• expand to multiple views/selins and make it one application
• create example queries and see them work same as sql native
• build sql/j variant of generation
• setup sqlj build chain and see examples work same everywhere

• inject schema-sql operator into sql parser
• detect ssql references in source and usage in query
• build jdbc(?) calls for self-description of schema of given source
• generate jdbc glue to materialize schema in temporal local database
• unroll ssql usage with selects on schema and generate jdbc glue
• check to use multiple database inputs w/o explicit joins but multiple cursors or nested selects
• create example queries to see them work same as 3rdparty points
• check for sqlj variant of generation

• move INTO target reference into source clause in sql (syntax)
• check for advantages in writing down queries and their generation
• move function imports into sql clause head (syntax)
• cross ref function usage in values and selects
• allow java function refs and build calls between cursor get/use
• check with predefined conversions for same sql vs generated
• check for aggregate functions working same