3 Replies Latest reply on Feb 4, 2014 2:23 PM by shawkins

    Translator Capabilities

    tom9729

      I'm diving into writing a translator to talk to my WS (web service). I've had success using the WS connector, and I've reached the point where I was with the WS translator (using a view to invokeHttp and map some results). My next task is to turn on some capabilities so that Teiid will push filters down to me.

       

      I think I know the answer to this question, but would like to make sure what I am doing makes sense.

       

      My WS supports ranged filtering on a timestamp, and IN/EQUALS on some other fields. It does not support ranged filtering on non-timestamp fields, and does not support IN/EQUALS for timestamp fields. I don't think there is any way to explain this to Teiid through metadata. Do I just need to identify these cases and do some filtering manually in my translator?

       

      Thanks,

      Tom

        • 1. Re: Translator Capabilities
          rareddy

          Yes, that much fine grained capabilities support is not available.  Generally you need to detect that situation in code and issue an exception. You can define a column searchable or not, if it is searchable it will be eligible for pushdown for EQUALS and IN and Compare etc.

           

          Ramesh..

          • 2. Re: Translator Capabilities
            tom9729

            Ramesh,

             

            I am using unsearchable for some fields. The tricky thing is with filter capabilities that depend on the column. What I am thinking of is the ability to specify some capabilities on the columns themselves. For example, column X supports RANGED and EQUALS; columns Y and Z support EQUALS and IN.

             

            Thanks,

            Tom

             

            Edit: Really just a clarification of my original post.

            • 3. Re: Translator Capabilities
              shawkins

              There have been other users with similar requirements, but typically it has been satisfied with a combination of searchability/capabilities.  This still seems to somewhat be straddling the notion of procedural access vs. a view - but that ultimately you want the client to access as a view correct?

               

              Somewhat related to [TEIID-236] Procedural access pattern - JBoss Issue Tracker there is a case to be made for a restriction to just equality, in, is null, which would get you most of the way toward what you are looking for.

               

              Steve

              1 of 1 people found this helpful