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

    Translator Capabilities

    Tom Arnold Novice

      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
          Ramesh Reddy Master

          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
            Tom Arnold Novice

            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
              Steven Hawkins Master

              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