Hi Manoj,

There isn't a single direct replacement.  They were both mostly replaced by just Expression, but the Select clause will still wrap non-symbol Expressions in an ExpressionSymbol to associate a name.  Then to get a name for an Expression you would use the static method Symbol.getName

Out of curiosity how are you making use of the internal language objects?

Steve

You should really invest in Redhat subscription for EDS then

Hi Steve -

Manoj is part of my team upgrading our code to the latest Teiid. 

We use Teiid's QueryParser and the related objects for programatically manipulating queries.  I believe the exact code that Manoj is working on is to take create a temp table, fill with with a SELECT statement after stripping ORDER BY and LIMIT clauses and then rewrite the original SELECT to operate against the temp table.

Obviously, operating against the AST is much easier than string manipulation and we'd rather use Teiid's own query parser.  I don't mind taking the productivity hit when Teiid internals change since, overall, it's a big win for us.

I am curious, though:  I *think* there's a JIRA to combine the internal AST objects with the public AST used by the translators.  Is that high on your priority list?  Combining those two would be a mental relief for those of us who operate in both worlds

Another thought that has rattled around in my brain:  Any chance of an API that accepts the AST objects directly?  As in the above example, we often take SQL (or pseudo-SQL), parse it using the QueryParser and then create the SQL string.  Even though I know it's super-cheap, it seems silly to have Teiid turn around and parse it again.

Hi, Ramesh -

We'd love to subscribe but with a paid subscription, we can only get an RH support contract for some backleveled version of Teiid.  Because we are typically using the cutting-edge code (not even released) and it's quite possible that we will ship a version of Teiid source to our customers that isn't covered by RH support, our contracts people have a fit.  So, we're kind of stuck.  I would welcome some way out of this problem.

Feel free to contact me directly (mark dot addleman at ca dot com) to discuss further.

> We use Teiid's QueryParser and the related objects for programatically manipulating queries.  I believe the exact code that Manoj is working on is to take create a temp table, fill with with a SELECT statement after stripping ORDER BY and LIMIT clauses and then rewrite the original SELECT to operate against the temp table.

Sounds like a custom internal materialized view.  Do you need more control over how the mat view gets created/manipulated?

> I am curious, though:  I *think* there's a JIRA to combine the internal AST objects with the public AST used by the translators.  Is that high on your priority list?  Combining those two would be a mental relief for those of us who operate in both worlds

Ideally the objects will be combined.  Possibly we would introduce a full AST out of the parser and for designer use, and then a single language object implementation (which is not a full AST as much of the original SQL is thrown away).  The priority hasn't been high enough to get an overhaul into a release.  Beyond so simple renaming there is a lot of logic on the engine objects as well as constructs that are not used by the translators - and any changes to the engine objects requires refactoring in the Designer as well.  So I've taken the approach of just making the two more similar with each release.

> Another thought that has rattled around in my brain:  Any chance of an API that accepts the AST objects directly?  As in the above example, we often take SQL (or pseudo-SQL), parse it using the QueryParser and then create the SQL string.  Even though I know it's super-cheap, it seems silly to have Teiid turn around and parse it again.

It's cheap compared to overall query execution, but understandably something that you would avoid if possible.  As part of the embedded effort I'll be adding a method to by-pass the parser and just use the engine objects - https://issues.jboss.org/browse/TEIID-2062.  But as always usage of an internal api will not be officially supported at this time.

Steve

Sounds like a custom internal materialized view.  Do you need more control over how the mat view gets created/manipulated?

 

I fear our requirement is the tantamount to dynamically constructing a view.  Our server gets dynamically constructed queries from the UI which we treat as views:  The user can page forward and backward (ie LIMIT and OFFSET) and the user can sort (ORDER BY) these queries.  Some of our tables are contain highly dynamic data (think the Linux "top" command) so our server metadata marks those tables as 'materializable' and that's where we create temp tables, fill the temp tables and rewrite the query to target the temp table instead.  All so the user has a stable result set to page through and sort.  Ideally, we'd dynamically construct a view (conceptually equivalent to temp table) for all user requests and mark some of them as materializable.

Now, with continuous executions, we're about to embark on a coding expedition to keep the temp tables up to date continuously and allow the user to freeze them (pause the continuous execution).  I'm not sure how much help Teiid can provide here.  Even if we could issue "INSERT INTO blah SELECT * FROM <continuous execution>" and keep the temp table up to date, we would still need a way to know when the data in the temp table has actually changed in order to push it out to the UI (the plan is to hash the data in the temp tables and compare hashes from before and after each result set from the continuous execution). 

So I've taken the approach of just making the two more similar with each release.

Makes sense.  The current approach is entirely workable.  Like I said, given the huge advantage we have in reusing QueryParser, I don't mind binding our code to possibly changing internals.  Quick question, though:  For unit testing our execution factories, I've wanted a way to convert from QueryParser objects to the translator objects?

It's cheap compared to overall query execution, but understandably something that you would avoid if possible.  As part of the embedded effort I'll be adding a method to by-pass the parser and just use the engine objects - https://issues.jboss.org/browse/TEIID-2062.  But as always usage of an internal api will not be officially supported at this time.

Cool.  As indicated above, the advantages may outweigh the instability.

> For unit testing our execution factories, I've wanted a way to convert from QueryParser objects to the translator objects?

There are lots of unit tests that do something similar.  Either references to the LanguageBridgeFactory or something like the TranslationUtility which was part of the old CDK concept.

Cool.  Thanks.