Skip to main content

Teiid 9.2.1 Released

Teiid 9.2.1 is now available.  This fix release covers 18 issues:
  • [TEIID-4765] - The notion of resolving order may need to be extended beyond a schema
  • [TEIID-4788] - DDL vdb is expensive to process
  • [TEIID-4809] - lob performance issues
  • [TEIID-4770] - The convert script generates empty GRANT statements for roles that don't have permission to access a certain schema.
  • [TEIID-4771] - The convert script generates GRANT TEMPORARY_TABLE ON DATABASE statements but these fail.
  • [TEIID-4774] - Convert VDB utility does not work when translator overrides are present
  • [TEIID-4776] - Issues with array type metadata
  • [TEIID-4783] - missing message keys for functions
  • [TEIID-4785] - Add options through alter table in DDL does not work.
  • [TEIID-4791] - Bypass lookup function's keycolumn reserved word
  • [TEIID-4797] - Oracle: empty catalog messed up VDB schemas name
  • [TEIID-4807] - DDL format of a vdb lacks import information
  • [TEIID-4652] - SybaseIQ translator: DAYOFYEAR function not pushed correctly
  • [TEIID-4653] - SybaseIQ translator: Input parameter not set in prepared statement in source command
  • [TEIID-4775] - External materialization, after transaction timeout, LoadState continues to be LOADING
  • [TEIID-4778] - External Materialization, When TTL is less than loading time, the scheduling is off
  • [TEIID-4780] - Clone TEIID-4734 (Backwards compatible solution)
  • [TEIID-4782] - Change framework to catch RutineException from translator/connector
Note that several of these are related to the new DDL vdb feature - thanks Bram Gadeyne for the initial feedback.  This feature will continue to evolve even in 9.2.x to maintain forward compatibility with 9.3.x.

Looking forward, Teiid 9.2.2 should be available in 3-4 weeks.



Popular posts from this blog

Teiid Runtimes Explained

If you have been following Teiid lately we have been going through a whole lot of renovations. Yes, renovations or reorganization or refactoring or whatever you want to call it. Basically, we are making Teiid more modular with fewer dependencies that can be used by however your use case dictates rather than use it as one monolith application deployed into WildFly JEE Application Server. There is nothing wrong in using Teiid as server model, but with the proliferation of container-based workloads and cloud-based architectures, the previous server-based model does not work or simply won't scale. So, we needed to think of alternatives, thus Teiid team introduced a couple different versions modular Teiid what we are calling as "Teiid Runtimes".

Note that in these modular Teiid runtimes, not all the features you were used to using in Teiid Server model may not be there but you will have extensions to add in those that are most appropriate for your domain. If you are looking …

Teiid Platform Sizing Guidelines and Limitations

Users/customers always ask us about the sizing of their Data Virtaulization infrastructure based on Teiid or the JDV product from Redhat. Typically this is very involved question and not a very easy one answer in plain terms. This is due to fact that it involves taking into consideration questions like:
What kind of sources that user is working with? Relational, file, CRM, NoSQL etc.How many sources they are trying to integrate? 10, 20, 100?What are the volumes of data they are working with? 10K, 100K, 1M+?What are the query latency times from the sources? How you are using Teiid to implement the data integration/virtualization solution. What kind of queries that user is executing? Even small federated results may take a lot of server side processing - especially if the plan needs tweaking.Is materializing being used?Is query written in optimal way?and so on..Each and every one of the question affects the performance profoundly, and if you got mixture of those then it become that much…

SQL on MongoDB using Teiid - Part 1

In this article series, I will showcase how you can use SQL based queries with MongoDB. In general there seems to be resurgence of SQL based access to all NoSQL based stores in the market space, take for example Hive, Impala, Spark, Apache Drill etc. The main reason for this shift is there are abundant amount of talent pool out there for SQL based developers, and even today (and years to come) our strong dependence on the relational stores for the enterprise data. I do not see either of them fading away any time soon. So utilizing the known skills on new types of data stores will save you lot of time and provide better integration with rest of your enterprise applications.

I know there are plenty of folks offering SQL based access to MongoDB, why you should choose Teiid?
Teiid provides full ANSI compatible SQL based access to MongoDB. This includes full SQL-92, and most SQL-99 and SQL-2003 support.Provides JDBC/ODBC access to execute SQL queries.Provides ODATA based access to MongoDB…