Skip to main content

Teiid 9.3.4 Released

Teiid 9.3.4 has been released.  It resolves 21 issues:
  • [TEIID-4567] - UCASE and LCASE functions do not work with CLOBs.
  • [TEIID-4870] - Google translator unexpected behavior for view update without trigger
  • [TEIID-5039] - Couchbase document type definition for a table
  • [TEIID-5041] - Couchbase documentID column enforced also in a view
  • [TEIID-5063] - Issues with bigdecimal values and odata
  • [TEIID-5065] - Unable to connect to VDB having names with unicode characters
  • [TEIID-5067] - Incorrect source query with simple inherent updates
  • [TEIID-5068] - Couchbase retrieval causes ClassCastException
  • [TEIID-5069] - Blob getBytes() handling of input streams reads the stream multiple times without a reset
  • [TEIID-5075] - Couchbase incorrect update count returned
  • [TEIID-5076] - Couchbase update syntax error
  • [TEIID-5077] - Couchbase strange behaviour for long numbers
  • [TEIID-5081] - FORMATTIMESTAMP is not pushed down to postgresql but formattimestamp is
  • [TEIID-5082] - Salesforce default URL incorrect
  • [TEIID-5085] - NullPointerException after SortUtility blocks in initialSort
  • [TEIID-5090] - Issues with matview scripts
  • [TEIID-5094] - Is DISTINCT FROM evaluation with two null values
  • [TEIID-5098] - Unsyncronized static date format for Salesforce bulk inserts
  • [TEIID-5104] - BigInteger mapped to string for OData 4
  • [TEIID-5107] - teiid-olingo-*.war not deploying in wildfly when using domain
  • [TEIID-5109] - Set operations and parenthesis
This fix pack was delayed slightly as several important issue came up prior to release.  Notice that Couchbase support continues to be refined, but the issues are getting more targeted to narrow functional areas.

Unfortunately we are still on hold with Teiid 10.0.0.CR2 as we wait on the release of WildFly 11.  It is expected any day now.  Teiid 10.0.0.Final should follow about a week after that.



Popular posts from this blog

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…

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 …