1 Reply Latest reply on Oct 9, 2014 3:14 PM by shawkins

    preprocess query in teiid embedded

    sudeepd

      I can figure this out from the code, but getting a response from the teiid team would save me some time...

      This is what I am trying to do:

      We have an existing application that calls into mssql jdbc. We are replacing that with the teiid jdbc, and federating between mssql and another DB. For this, we have teiid embedded running good and proper over sockets

      We however, need to preprocess/rewrite the query to

      a. fully qualify the tables,

      b. add the makedep and makeind join hints,

      c. replace some of the  functions in the incoming query with equivalent functions that can be pushed down to the other DB.

       

      I dont want to introduce another shim layer between teiid and our application to do this... it would be very useful if we can register a callback to embedded or something similar to get the query and preprocess it before teiid processes it. Is there a recommended/supported way to do this ? If not , what are my options ?

        • 1. Re: preprocess query in teiid embedded
          shawkins

          a)  Will the query not resolve without additional qualification?

           

          b) This may be difficult to do positionally, would you be using the options clause?

           

          c) This can be done without directly manipulating the query.  If you add the metadata for the functions to be replaced as UDFs and add support for them at the translator level via the getSupportedFunctions method, they will be pushed down and can be handled at the translator level - see the FunctionModifier class usage.

           

          And in general there's an approach similar to c that is to direct the query as a pushdown to a fronting Teiid vdb so that you can just manipulate the pushdown command and have that submitted to you actual vdb that performs the desired federation.

           

          Otherwise we have an unofficial hook to modify the command in the internal form via a custom AuthorizationValidator - that has access to the raw instance.  However this is the already parsed/resolved query.  If you need access to just the string form you may want to consider just using proxy of other interception logic on the the client side.