Contents
LiveView 10.5.0 adds the following updates and new features:
- LiveView Data Table Trimming Option Now Added
-
LiveView now includes the option to set retention policies for maintaining table data. See Retention Policy for more information.
- New Row Level Security Privilege Added
-
LiveView now supports restricting access to specified rows in LiveView tables for a given user. See Setting Row Level Security for LiveView Tables for details.
- Cluster-wide Alerting Now Added
-
LiveView supports a cluster-wide alerting service to share alerts across backend LiveView servers. See this page for details.
The LVAlertRulesStatus system table now includes the ServerRole and AlertGroup columns to accommodate this feature.
- New LiveView Table Group Strategy Added
-
A new high availability table group strategy allows HA tables to keep all queries from a single session on a single back end server. See Configuration Strategies for details.
- New Hash Algorithm Added to Improve Snapshot Parallelism
-
A snapshot parallelism algorithm was added to improve load and query performance where a query needs to scan many rows of a LiveView table. See Using Parallelism and Concurrency for details.
- White List Now Added For Execute Java Alert Actions
-
LiveView Execute Java Alert Actions now have their configured class validated against a configurable server wide white list. There is a system property
liveview.alert.execjava.class.whitelist.globwhich is set to a semicolon-separated list of globs that represent acceptable classes to invoke. The property has a default value of:com.tibco.ldm.sample.*. - New Command Option Added to Compress Exported Metadata Files
-
The exportmetadata command now includes an option to compress exported metadata files. See the lv-client command page for details.
- New REST Alert Action Added
-
A new action was added to LiveView alerts, which can optionally call REST endpoints (GET, POST, PUT, PATCH, DELETE) when the alert triggers. See this page for configuration details, or the LiveView Alerting sample's README to demonstrate the action.
- New System Property Added to Display IP Addresses Forwarded Through Proxies
-
A new system property
liveview.server.forwards.usewas added to access the originating IP address of a request when it is forwarded through a proxy. - New Metadata Store Database Options Available
-
The LiveView Metadata store now supports Oracle 18c, Microsoft SQL Server 2017, and MySQL 8.0 databases.
- Reliable LiveView Client Publishing Now Supported
-
The LiveView Java client API now supports a feedback mechanism to allow clients to register publishers on the LiveView server and solicit feedback at scheduled intervals. All acknowledgements for published tuples are sent back on a listener to verify tuples were published. Refer to the Javadoc for details.
The LVSessionPublishers system table now includes the LastPersistedSN and renamed LastPublishedSN (was LastPublishedID) columns to accommodate this feature.
A new Reliable Publish Sample is available for LiveView as well. See the Adapter Guide for details.
- New LiveView System Table Added for Node Status
-
The LiveView system table LVNodeInfo was added to show information about LiveView nodes.
This release includes the following changes in functionality:
- New Data Source for LiveView Connectivity Wizard
-
The LiveView Connectivity Wizard now offers to create a simple LiveView server instance from a TIBCO Cloud Messaging service in addition to the data sources previously supported.
- LiveView Desktop Now Based on Eclipse 4.12
-
TIBCO LiveView Desktop™ and LiveView Desktop Workspace Manager are now based on Eclipse 4.12. As a result, these applications now install and run only on 64-bit Windows. The installers for these applications reflect the 64-bit change in their file names, now ending with
_win_x86_64.msi. LiveView Desktop users may be prompted to upgrade their workspace format, which proceeds automatically and silently once permission is granted.This change also affects TIBCO StreamBase Studio™ and StreamBase Manager, as described in New Features .
- LiveView Engine Configuration Now Supports EventFlowDeployment Root Object
-
EventFlowDeployment root objects are now supported in the
com.tibco.ep.ldm.configuration.ldmengineconfiguration type. Note that since EventFlowDeployment objects are deploy-time and LDMEngine objects are typically design-time, you would typically not combine them into one configuration file, but you are now free to do so if your application deployment requires it. - LiveView ORDER BY Queries Now Conflate Updates and Results by Default
-
By default ORDER BY queries now conflate updates and results, which are calculated and emitted once per second. This means it is possible for ephemeral data — such as data that is added and remove quickly — to never appear to the client. Previously, every event recalculated ORDER BY and potentially emitted updates.
You can control the conflation period for
alltables by setting the system propertyliveview.topn.calc.period.defaultto the number of milliseconds you want to wait between updates. You can changesingletables by settingliveview.topn.calc.period.tablenameSetting the period to 0 returns to previous behavior where every event recalculates ORDER BY.
- LiveView Client Connections No Longer Accept Enciphered Passwords in URIs
-
For security reasons, LiveView client connections now require that you provide an actual password in URIs when authentication is enabled. Connections no longer accept enciphered passwords in URIs.
LiveView 10.5.0 has the following deprecations.
- Calculated Column Query Privilege Deprecated and Removed
-
The LiveView table management privilege,
LiveViewTableCCQuery, which was deprecated in 10.4.3 is removed from 10.5.0.When upgrading a LiveView project containing the
LiveViewTableCCQueryprivilege to 10.5.0, you must remove the privilege from the role-to-privilege mapping configuration in order to compile your LiveView project. - Deprecated Legacy Alert ID and Related APIs Now Removed
-
The AlertRuleGUID column was added to the LVAlerts and LVAlertRulesStatus system tables in 10.3.0. As a result, the deprecated AlertRuleID column is now removed in 10.5.0 from these tables.
Deprecated LiveView Java and .NET client API methods were also removed, including those for LiveView Desktop and LiveView Workspace Manager. See the respective client API documentation for details.
With the removal of AlertRuleID, pre-10.3.0 clients will not be able to see or modify alerts when connected to LiveView 10.5.0 servers. TIBCO therefore recommends updating LiveView clients to at least 10.3.0.
- JavaScript API Now Changed for Tuple ID
-
In this release, the tuple ID algorithm was changed to reduce ID collisions. You may required to remove user-persisted IDs if you use the JavaScript API and persist the tuple ID across server reboots.
- Atmosphere JavaScript Library Now Upgraded
-
The Atmosphere JavaScript library was upgraded to version 2.5.2.
- Metadata Resources File Name Now Changed
-
LiveView supports loading metadata resources on the startup. Prior to 10.5.0, the default name for the file was
resources.json. As of 10.5.0, the file name changed tolvmetadata.json. For backward compatibility, the deprecatedresources.jsonfile name continues to be supported; support is expected to be removed in a future release.
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‑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. | |
| SB‑46418 | Removing lvweb.war dependency from a project's POM does not remove the file, and vice versa.
|
|
| Description | New LiveView Fragment projects are created by default with a dependency on the lvweb.war file that implements LiveView Web functionality. There are two cases: (1) If you later edit the project's pom.xml file to remove that <dependency> element, doing so does not automatically remove the lvweb.war file from the project's src/main/liveview/lv-user-webapps folder. (2) If you remove the lvweb.war file manually, the pom.xml is not automatically edited to remove the dependency.
|
|
| Workaround | In both cases, you must both remove the lvweb.war file and edit the pom.xml file to remove a project's support for LiveView Web.
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. | |
| Workaround | If you are using one of the affected releases, you can;
|
|
| SB‑44494 | Metadata store restriction for clusters containing LiveView and StreamBase fragments. | |
| Description | The transactional memory metadata store type is only supported on homogeneous LiveView clusters. This means the cluster cannot contain a mix of LiveView and StreamBase fragments when using a transactional
memory metadata store.
|
|
| 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. | |
| Workaround | None. | |
| CQS‑4748 | Do not use the liveview.project.out system property.
|
|
| Description | The liveview.project.out system property was recommended in previous releases as a way to manage the placement of the LiveView server's compilation
working directory. However, if you redirect this working directory in StreamBase 10 applications, the StreamBase application
may fail to start correctly.
|
|
| Workaround | None. | |
| 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. | |
| Workaround | Instead use StreamBase Unicode escape sequences, which looks like \uXXXX. For example, a bell is \u0007.
|
|
| CQS‑4467 | An aggregate query with HAVING clause and LIMIT specified may throw a Query updates exceeded specified limit error when the number of rows returned are less than the specified LIMIT.
|
|
| 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. | |
| Workaround | 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 Query updates exceeded specified limit is appropriate.
|
|
| CQS‑3855 | Remote data source tables with sole primary key CQSInternalID cannot be opened.
|
|
| Description | 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. |
|
| Workaround | 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. | |
| Description | 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 when transactionTime between now()-minutes(5) and now().
|
|
| Workaround | If you only want a time-windowed expression in the <predicate> element of the lvconf, prefix it with the simple StreamBase
expression true. For example: |
|
| CQS‑2659 | Cannot create destination directory error in LiveView Desktop connection dialog.
|
|
| Description | Start LiveView Desktop. In the initial Connect to LiveView dialog, after selecting a valid LiveView Server's URL, the connection
fails with the message Cannot create destination directory.
|
|
| 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.5.0 of the TIBCO LiveView™ component of TIBCO® Spotfire Data Streams.
| Fixed in 10.5.0 | |
|---|---|
| Number | Resolution |
| TIBCO LiveView™ 10.5.0 incorporates all fixes resolved in the release 10.0 series through 10.4.4 and all fixes resolved in the release 2.2 series through 2.2.7. | |
| CQS‑5004 | In some cases, spurious errors were being shown in the Source tab of the LiveView Configuration File Editor. These were fixed. |
| General | Alerts stored using the multiple server support feature introduced in 10.3.0, while accurately stored, did not have a mechanism to determine which LiveView server instance should run the alert. The cluster wide alerting feature introduced in 10.5.0 resolves this issue. |