LiveView 10.6.1 adds the following updates and new features:
- New LiveView Delayed Peer Recovery Sample for TCM eFTL Now Available
The Delayed Peer Recovery sample uses a new custom operator to implement peer recovery that is delayed/overlapped, to better support message buses that cannot deliver messages not previously subscribed to. This is an important use case for elastic scaling HA servers.
LiveView 10.6.1 has the following deprecations.
- Client API for TIMESTAMP_RELATIVE Now Deprecated
The Java and .NET Client API for TIMESTAMP_RELATIVE is now deprecated. Use TIMESTAMP_INTERVAL instead. Refer to the respective API documentation for details.
LiveView 10.6.1 contains the following migration and compatibility notes.
- TIMESTAMP_INTERVAL API Now Replaces TIMESTAMP_RELATIVE
The Java and .NET client API for TIMESTAMP_INTERVAL now replaces TIMESTAMP_RELATIVE, which is now deprecated. Refer to the respective API documentation for details.
This page describes the known limitations in the current release of TIBCO LiveView™. Each item includes a tracking number, description, and whenever possible, one or more workarounds.
|ClusterAlert||Cluster-wide Alert Group Restriction for Heterogeneous Clusters|
|Description||Nodes with only EventFlow engines in LiveView clusters must be in their own alert groups.|
|Workaround||See this page for cluster-wide alerting guidelines.|
|CQS‑5193||Benign NPE warning seen during LiveView fragment startup.|
A NullPointerException WARN message that mentions
|CQS‑5021||Exception when adding alert rule, yet the alert is actually added.|
|Description||An exception can occur when adding an alert rule on a mapped table, on the front end LiveView server, because the backend table name is different. When this happens, however, the alert is actually added on the mapped front end table name, but is not triggered because that table does not exist on the backend server.|
|Workaround||Set the alert on the underlying table name, not the mapped table name nor table alias visible on the front end server.|
New LiveView Fragment projects are created by default with a dependency on
In both cases, you must both remove the
The correct way to create a new
LiveView project without LiveView Web support is to change the
|SB‑45720||Failure to independently run or debug EventFlow modules in LiveView projects in 10.4.0 through 10.4.2.|
|Description||Many LiveView projects have StreamBase EventFlow modules that provide functionality such as publishers or transformers of data. In releases 10.4.0, 10.4.1, and 10.4.2, right-clicking such modules and selecting> (or ) to run or debug the module independent of the enclosing LiveView project resulted in an error. This feature was restored in release 10.4.3. Note that this limitation did not prevent running the project as a LiveView fragment with all EventFlow modules working; the limitation was only on running the EventFlow modules by themselves.|
If you are using one of the affected releases, you can;
|SB‑44494||Metadata store restriction for clusters containing LiveView and StreamBase fragments.|
The transactional memory metadata store type is only supported on
|Workaround||Use either the JDBC or H2 metadata store type when your cluster contains both LiveView and StreamBase fragments.|
|CQS‑4800||Row level security — authentication not performed on results of already-registered queries and query-based alerts.|
|Description||Row level security (RLS) authentication and authorization is performed at the time when new query-based alerts and queries are registered with the LiveView server. LiveView does not perform authentication on the results of already-registered queries and query-based alerts; in order to get the expected results based on RLS authentication, you must re-register the queries with the server.|
Do not use the
|CQS‑4641||Issuing queries with literal non-printing characters is not supported in query strings.|
|Description||Query strings with literal non-printing characters can cause issues. Non-printing characters are those below 0x20, excepting tab, carriage return, and line feed. Note that tables and query result sets are free to have any characters as values.|
Instead use StreamBase Unicode escape sequences, which looks like
An aggregate query with HAVING clause and LIMIT specified may throw a
|Description||When issuing an aggregate query with a HAVING clause and LIMIT applied, returned rows may be less that the specified LIMIT (even none). This is because LIMIT is applied to the rows returned before the HAVING predicate filter.|
If the HAVING predicate is expected to filter a large number of rows, use a
very large LIMIT or no LIMIT. For non-aggregate queries with a HAVING and
LIMIT, the number of rows you get before getting a
Remote data source tables with sole primary key
When querying a remote data source's tables, all LiveView clients fail to
open any remote table that uses a single primary key named CQSInternalID.
This issue affects all LiveView clients, including TIBCO LiveView Desktop, TIBCO LiveView Web, the lv-client command line utility, and any custom client written using LiveView Client APIs.
The issue occurs when querying any remote data source, including: TIBCO StreamBase Query Tables, other LiveView servers, JDBC databases, TIBCO ActiveSpaces tables, and custom table providers.
You can use one of the following suggestions to enumerate the remote tables
that you must avoid. 1. If your client can sort its list of available remote
tables, sort it by the Indexes column to isolate the tables that have only
CQSInternalID as their primary key. 2. Use the following query to determine
the remote tables to avoid opening:
select * from LVTables where Indices=='CQSInternalID'
|CQS‑3383||LiveView Desktop can return results into one column instead of several.|
|Description||Under some circumstances, if a query starts, then ends very quickly in an error condition (such as reaching a row limit almost immediately), LiveView Desktop might display the results using a single, unlabeled column, with every data row showing field values separated by commas, rather than displaying them in individual columns.|
|Workaround||Investigate the cause of the error condition and correct it, if possible, perhaps by increasing the row limit value.|
|CQS‑3355||LiveView Desktop — Newly added table columns do not appear by default in query grid views.|
|Description||When LiveView Desktop has previously been used to query a Data Table, new columns added to the Data Table after the initial query was performed may not appear automatically in subsequent queries.|
|Workaround||There are two workarounds for this issue. The first is to close all open Query Results views and delete the existing queries from your LiveView Tables view. Locate the Delete Recent Queries function in the context menu of the Recent Queries menu item nested under the desired data table in the Tables view. An alternative workaround is to use the context menu of the existing Query Results view and select Columns. Any newly added columns should be present in the Available list in the Column Chooser dialog and can be added to the Chosen column list.|
|CQS‑3287||LiveView with multiple count_distinct() expressions in one projection can return invalid results.|
|Description||If a Data Table has any case insensitive fields, and a query has a projection with more than one count_distinct() function with identical parameters, the resulting count_distinct values are likely to be incorrect.|
|Workaround||None. It is expected to be very unusual that a projection would have more then one count_distinct() function with identical parameters.|
|CQS‑2820||Time-windowed predicates not working as expected in author-time aggregation.|
In author-time aggregation, where you enter a query in an aggregation data
table's lvconf definition, the predicate must always start with a simple
StreamBase expression that results in a Boolean type. You cannot start with a
time-windowed predicate expression such as
If you only want a time-windowed expression in the <predicate> element
of the lvconf, prefix it with the simple StreamBase expression
Start LiveView Desktop. In the initial Connect to LiveView dialog, after
selecting a valid LiveView Server's URL, the connection fails with the
|Workaround||The message refers to the local directory used to contain workspaces for LiveView Desktop. Click to open the Advanced Options control, and make sure the Store workspaces in field is not blank. If it is, enter your desired path, or click the button. Then try the connection again.|
|CQS‑1692||Referencing a JDBC table that has not been properly loaded prevents LiveView Server from starting.|
|Description||JDBC tables are not automatically started as part of a LiveView Server project start. This means that if you configure a project with a JDBC table, you must load the database before starting LiveView Server.|
|Workaround||Start the JDBC database before starting LiveView Server.|
This section provides a list of errors corrected in release 10.6.1 of the TIBCO LiveView™ component of TIBCO® Spotfire Data Streams.
|Fixed in 10.6.1|
|TIBCO LiveView™ 10.6.1 incorporates all fixes resolved in the release 10.0 series through 10.5.0 and all fixes resolved in the release 2.2 series through 2.2.8.|
|CQS‑5049, CQS‑5141||As a side effect of Release 10.6.0's adoption of JDK 11, red warning lines appeared in the Studio Console view when starting a LiveView fragment. The warning that was emitted is now fixed by an update to the HTTP client.|