Version 7.2

• 1: New Features
• 2: Preview Features (experimental)
• 3: Breaking Changes
• 4: Upgrade Notes
• 5: Change Log

1 - New Features

Look and Feel

New User Interface Design

The user interface has had a bit of a re-design to give it a more modern look and to make it conform to accessibility standards.

User Preferences

Now you can customise Stroom with your own personal preferences. From the main menu , select:

You can also change the following:

• Layout Density - This controls the layout spacing to fit more or less user interface elements in the available space.

• Font - Change font used in Stroom.

• Font Size - Change the font size used in Stroom.

• Transparency - Enables partial transparency of dialog windows. Entirely cosmetic.

Theme

Choose between the traditional light theme and a new dark theme with light text on a dark background.

Editor Preferences

The Ace text editor used within Stroom is used for editing things like XSLTs and viewing stream data. It can now be personalised with the following options:

• Theme - The colour theme for the editor. The theme options will be applicable to the main user interface theme, i.e. light/dark editor themes. The theme affects the colours used for the syntax highlight content.

• Key Bindings - Allows you to set the editor to use Vim key bindings for more powerful text editing. If you don’t know what Vim is then it is best to stick to Standard. If you would like to learn how to use Vim, install vimtutor. Note: The Ace editor does not fully emulate Vim, not all Vim key bindings work and there is limited command mode support.

• Live Auto Completion - Set this to On if you want the editor code completion to make suggestions as you type. When set to Off you need to press Ctrl ^ + Space ␣ to show the suggestion dialog.

Date and Time

You can now change the format used for displaying the date and time in the user interface. You can also set the time zone used for displaying the date and time in the user interface.

Dashboard Changes

Design Mode

A Design Mode has been introduced to Dashboards and is toggled using the button . When a Dashboard is in design mode, the following functionality is enabled:

• Adding components to the Dashboard.
• Removing components from the Dashboard.
• Moving Dashboard components within panes, to new panes or to existing panes.
• Changing the constraints of the Dashboard.

On creation of a new Dashboard, Design Mode will be on so the user has full functionality. On opening an existing Dashboard, Design Mode will be off. This is because typically, Dashboards are viewed more than they are modified.

Visual Constraints

Now it is possible to control the horizontal and vertical constraints of a Dashboard. In Stroom 7.0, a dashboard would always scale to fit the user’s screen. Sometimes it is desirable for the dashboard canvas area to be larger than the screen so that you have to scroll to see it all. For example you may have a dashboard with a large number of component panes and rather than squashing them all into the available space you want to be able to scroll vertically in order to see them all.

It is now possible to change the horizontal and/or vertical constraints to fit the available width/height or to be fixed by clicking the button.

The edges of the canvas can be moved to shrink/grow it.

Explorer Filter Matches

Filtering in the explorer has been changed to highlight the filter matches and to search in folders that themselves are a match. In Stroom v7.0 folders that matched were not expanded. Match highlighting makes it clearer what items have matched.

Document Permissions Screen

The document and folder permissions screens have been re-designed with a better layout and item highlighting to make it clearer which permissions have been selected.

Editor Completion snippets

The number of available editor completion snippets has increased. For a list of the available completion snippets see the Completion Snippet Reference.

Partitioned Reference Data Stores

In Stroom v7.0 reference data is loaded using a reference loader pipeline and the key/value pairs are stored in a single disk backed reference data store on each Stroom node for fast lookup. This single store approach has led to high contention and performance problems when purge operations are running against it at the same time or multiple reference Feeds are being loaded at the same time.

In Stroom v7.2 the reference data key/value pairs are now stored in multiple reference data stores on each node, with one store per Feed. This reduces contention as reference data for one Feed can be loading while a purge operation is running on the store for another Feed or reference data for multiple Feeds can be loaded concurrently. Performance is still limited by the file system that the stores are hosted on.

All reference data stores are stored in the directory defined by stroom.pipeline.referenceData.lmdb.localDir.

Improved OAuth2.0/OpenID Connect Support

The support for Open ID Connect (OIDC) authentication has been improved in v7.2. Stroom can be integrated with AWS Cognito, MS Azure AD, KeyCloak and other OIDC Identity Providers .

Data receipt in Stroom and Stroom-Proxy can now enforce OIDC token authentication as well as certificate authentication. The data receipt authentication is configured via the properties:

• stroom.receive.authenticationRequired
• stroom.receive.certificateAuthenticationEnabled
• stroom.receive.tokenAuthenticationEnabled

Stroom and Stroom-Proxy have also been changed to use OIDC tokens for API endpoints and inter-node communications. This currently requires the OIDC IDP to support the client credentials flow.

Stroom can still be used with its own internal IDP if you do not have an external IDP available.

User Naming Changes

The changes to add integration with external OAuth 2.0/OpenID Connect identity provides has required some changes to the way users in Stroom are identified.

Previously in Stroom a user would have a unique username that would be set when creating the account in Stroom. This would typically by a human friendly name like jbloggs or similar. It would be used in all the user/permission management screens to identify the user, for functions like current-user(), for simple audit columns in the database (create_user and update_user) and for the audit events stroom produces.

With the integration to external identity providers this has had to change a little. Typically in OpenID Connect IDPs the unique identity of a principle (user) is fairly unfriendly UUID . The user will likely also have a more human friendly identity (sometimes called the preferred_username) that may be something like jblogs or jblogs@somedomain.x. As per the OpenID Connect specification, this friendly identity may not be unique within the IDP, so Stroom has to assume this also. In reality this identity is typically unique on the IDP though. The IDP will often also have a full name for the user, e.g. Joe Bloggs.

Stroom now stores and can display all of these identities.

• Display Name - This is the (potentially non-unique) preferred user name held by the IDP, e.g. jbloggs or jblogs@somedomain.x.
• Full Name - The user’s full name, e.g. Joe Bloggs, if known by the IDP.
• Unique User Identity - The unique identity of the user on the IDP, which may look like ca650638-b52c-45af-948c-3f34aeeb6f86.

In most screens, Stroom will display the Display Name. This will also be used for any audit purposes. The permissions screen show all three identities so an admin can be sure which user they are dealing with and be able to correlate it with one on the IDP.

User Creation

When using an external IDP, a user visiting Stroom for the first time will result in the creation of a Stroom User record for them. This Stroom User will have no permissions associated with it. To improve the experience for a new user it is preferable for the Stroom administrator to pre-create the Stroom User account in Stroom with the necessary permissions.

This can be done from the Application Permissions screen accessed from the Main menu ( ).

You can create a single Stroom User by clicking the button.

Or you can create multiple Stroom Users by clicking the button.

In both cases the Unique User ID is mandatory, and this must be obtained from the IDP. The Display Name and Full Name are optional, as these will be obtained automatically from the IDP by Stroom on login. It can be useful to populate them initially to make it easier for the administrator to see who is who in the list of users.

Once the user(s) are created, the appropriate permissions/groups can be assigned to them so that when they log in for the first time they will be able to see the required content and be able to use Stroom.

New Document types

The following new types of document can be created and managed in the explorer tree.

Documentation

It is now possible to create a Documentation entity in the explorer tree. This is designed to hold any text or documentation that the user chooses to write in Markdown format. These can be useful for providing documentation within a folder in the tree to collectively describe all the items in that folder, or to provide a useful README type document. It is not possible to add documentation to a folder entity itself, so this is useful substitute.

Elastic Cluster

Elastic Cluster provides a means to define a connection to an Elasticsearch Cluster. You would create one of these documents for each Elasticsearch cluster that you want to connect to. It defines the location and authentication details for connecting to an elastic cluster.

Thanks to Pete K for his help adding the new Elasticsearch integration features.

Elastic Index

An Elastic Index document is a data source for searching one or more indexes on Elasticsearch.

New Searchables

A Searchable is one of the data sources that appear at the top level of the tree pickers but not in the explorer tree.

Analytics

Adds the ability to query data from Table Builder type Analytic Rules.

New Pipeline Elements

DynamicIndexingFilter

This filter element is used by Views and Analytic Rules. Unlike IndexingFilter where you have to specify all the fields in the index up front for them to visible to the user in a Dashboard, DynamicIndexingFilter allows fields to be dynamically created in the XSLT based on the event being indexed. These dynamic fields are then ‘discovered’ after the event has been added to the index.

DynamicSearchResultOutputFilter

This filter element is used by Views and Analytic Rules. Unlike SearchResultOutputFilter this element can discover the fields found in the extracted event when the extraction pipeline creates fields that are not present in the index. These discovered field are then available for the user to pick from in the Dashboard/Query.

ElasticIndexingFilter

ElasticIndexingFilter is used to pass fields from an event to an Elasticsearch cluster to index.

Explorer Tree

Various enhancements have been made to the explorer tree.

Favourites

Users now have the ability to mark explorer tree entities as favourites. Favourites are user specific so each user can define their own favourites. This feature is useful for quick access to commonly used entities. Any entity or Folder at any level in the explorer tree can be set as a favourite. Favourites are also visible in the various entity pickers used in Stroom, e.g. Feed pickers.

An entity/folder can be added or removed from the favourites section using the context menu items :

An entity that is a favourite is marked with a in the main tree.

A change to a child item of a folder marked as a favourite will be reflected in both the main tree and the favourites section. All items marked as a favourite will appear as a top level item underneath the Favourites root, even if they have an ancestor folder that is also a favourite.

Thanks to Pete K for adding this new feature.

Document Tagging

You can now add tags to entities or folders in the explorer tree. Tags provide an additional means of searching for entities or folders. It allows entities/folders that reside in different folders to be associated together in one or more ways.

The tags on an entity/folder can be managed from the explorer tree context menu item:

The explorer tree can be filtered by tag using the field prefix tag:, i.e. tag:extraction.

If multiple entities/folders are selected in the explorer tree then the following menu items are available:

Pre-populated Tag Filters

Stroom comes pre-configured with some default tags. The property that sets these is stroom.explorer.suggestedTags. The defaults for this property are dynamic, extraction and reference-loader

These pre-configured tags are also used in some of the tree pickers in stroom to provide extra filtering of entities in the picker. For example when selecting a Pipeline on an XSLT Filter the filter on the tree picker to select the pipeline will be pre-populated with tag:reference-loader so only reference loader pipelines are included.

The following properties control the tags used to pre-populate tree picker filters:

• stroom.ui.query.dashboardPipelineSelectorIncludedTags
• stroom.ui.query.viewPipelineSelectorIncludedTags
• stroom.ui.referencePipelineSelectorIncludedTags

Copy Link to Clipboard

It is not possible to easily copy a direct link to a Document from the explorer tree. Direct links are useful if for example you want to share a link to a particular stroom dashboard.

To create a direct link, right click on the document you want a link for in the explorer tree and select:

You can then paste the link into a browser to jump directly to that document (authenticating as required).

Dependencies

It is not possible to jump to the Dependencies screen to see the dependencies or dependants of a particular document. In the explorer tree right click on a document and select one of:

Broken Dependency Alerts

It is now possible to see alert icons in the explorer tree to highlight documents that have broken dependencies. The user can hover over these icons to display more information about the broken dependency. The explorer tree will show the alert icon against all documents with a broken dependency and all of its ancestor folders.

A broken dependency means a document (e.g. an XSLT) has a dependency on another document (e.g. a reference loader Pipeline) but that document does not exist. Broken dependencies can occur when a user deletes a document that other documents depend on, or by a partial import of content.

This feature is disabled by default as it can have a significant effect on performance of the explorer tree with large trees. To enable this feature, set the property stroom.explorer.dependencyWarningsEnabled to true.

Once enabled at the system level by the property, the display of alerts in the tree can be enabled/disabled by the user using the Toggle Alerts button.

Entity Documentation

It is now possible to add documentation to all entities / documents in the explorer tree, e.g. adding documentation on a Feed. Each entity now has a Documentation sub-tab where the user can enter any documentation they choose about that entity. The documentation is written in Markdown syntax. It is not possible to add documentation to a Folder but you can create one or more a Documentation entities as a child item of that folder, see Documentation.

Find Content

You can now search the content of entities in the explorer tree, e.g. searching within XSLTs, Dictionaries, Pipeline structure, etc. This feature is available from the main menu :

It can also be accessed by hitting Ctrl ^ + Shift ⇧ + f (unless an editor pane has focus).

It is useful for finding which pipelines are using a certain element, or what XSLTs are using a certain stroom: function.

This is an early evolution of this feature and it is likely to be improved with time.

Search Result Stores

When a Dashboard/Query search is run, the results are written to a Search Results Store for that query. This stores reside on disk to reduce the memory used by queries. The Search Result Stores are stored on a single Stroom node and get created when a query is executed in a Dashboard, Query or Analytic Rule.

This screen provides an administrator with an overview of all the stores currently in existence in the Stroom cluster, showing details on their state and size. It can also be used to stop queries that are currently running or to delete the store entirely. Stores get deleted when the user closes the Dashboard or Query that created them.

Pipeline Stepper Improvements

The pipeline stepper has had a few user interface tweaks to make it easier to use.

Log Pane

When there are errors, warnings or info messages on a pipeline element they will now also be displayed in a pane at the bottom. This makes it easer to see all messages in one place.

The editor still displays icons with hover tips in the gutter on the appropriate line where the message has an associated line number.

The log pane can be hidden by clicking the icon.

Highlighting

The pipeline displayed at the top of the stepper now highlights elements that have log messages against them. This makes it easier to see when there is a problem with an element as you step through the data. The elements are given a coloured border according to the highest severity message on that element:

• Info - Blue
• Warning - Yellow
• Error - Red
• Fatal Error - Red (pulsating)

Filtering

Stroom has always had the ability to filter the data being stepped, however the feature was a little hidden (the Mange Step Filters icon).

Now you can right click on a pipeline element to manage the filters on that element. You can also clear its filters or the filters on all elements.

The pipeline now shows which elements have an active filter by displaying a filter icon.

Server Tasks

Auto Refresh

You can now enable/disable the auto-refreshing of the Server Tasks table using the button. Auto refresh is enabled by default. Disabling it is useful when you want to delete a task, as it will stop the table being refreshed just before you hit delete.

Line Wrapping

You can now enable/disable line wrapping in the Name and Info cells using the button. Line wrapping is disable by default. Enabling this is useful to see long Info cell values.

Info Popup

The Info popup has been changed to include the value from the Info column.

Proxy

Stroom-Proxy v7.2 has undergone a significant re-write in an attempt to address certain performance issues, make it more flexible and to allow data to be forked to many destinations.

2 - Preview Features (experimental)

New Document types

View

A View is a document type that has been added in to make using Dashboards and Queries easier. It encapsulates the data source and an optional extraction pipeline.

Previously a user wanting to create a Dashboard to query Stroom’s indexes would need to first select the Index to use as the data source then select an extraction pipeline. The indexes do not typically store the full event, so extraction pipelines retrieve the full event from the stream store for each matching event returned by the index. Users should not need to understand the distinction between what is held in the index and what has to be exacted, nor should they need to know how to do that extraction.

A View abstracts the user from this process. They can be configured by an admin or more senior user so that a standard user can just select an appropriate View as the data source in a Dashboard or Query and the View will silently handle the retrieval/extraction of data.

Views are also used by Analytic Rules so need to define a Meta filter that controls the streams that will be processed by the analytic. This filer should mirror the processor filter expression used to control data processed by the Index that the View is using. These two filters may be amalgamated in a future version of Stroom.

Query

The Query feature provides a new way to query data in Stroom. It is a functional but evolving feature that is likely to be enhanced further in future versions.

Rather than using the query expression builder and table column expressions as used in Dashboards, it uses the new text based Stroom Query Language to define the query.

Stroom Query Language (StroomQL)

This is an example of a StroomQL query. It replaces the old dashboard expression ’tree’ and table column expressions. StroomQL has the advantage of being quicker to construct and is easier to copy from one query to another (whole or in part) as it is just plain text.

FROM "Example View"                           // Define the View to use as the data source
WHERE Action IN("Search", "View")             // Equivalent to the Dashboard expression tree
EVAL hour = floorHour(EventTime)              // Define named fields based on function expressions
EVAL event_count = count()
GROUP BY Feed, Action                         // Equivalent to Dashboard table column grouping
SELECT Feed, Action, event_count AS "Count"   // Equivalent to adding columns to a Dashboard table

Editing StroomQL queries in the editor is also made easier by the code completion (using ctrl+space) to suggest data sources, fields, functions and StroomQL language terms. StroomQl queries can be executed easily with ctrl+enter or shift+enter.

Analytic Rule

Analytic Rules allow the user to create scheduled or streaming Analytic Rule that will fire alerts when events matching the rule are seen.

Analytic rules rely on the new Stroom Query Language to define what events will match the rule. An Analytic Rule can be created directly from a Query by clicking the Create Analytic Rule icon.

3 - Breaking Changes

Quoted Strings in Dashboard Table Expressions

Quoted strings in dashboard table expressions can now be expressed with single and double quotes. As part of this change apostrophes in text are no longer escaped with an additional apostrophe (''), but instead require a leading \ before them if they are in a single quoted string, i.e:

'O''Neill' must be changed to 'O\'Neill'

In many cases it is preferable to use double quotes if the string in question has an apostrophe. Note that the use of \ as an escape character also means that any existing \ characters will need to be escaped with a preceding \ so \ must now become \\, i.e:

c:\Windows\System32 must be changed to c:\\Windows\\System32

The new Find Content feature can be used to find affected Dashboards.

Search API Change

The APIs for running searches against Stroom data sources have changed in a breaking way. This is due to a change in the way running queries are identified.

Previously the client calling the API would provide generate a unique key for the query and included it in the searchRequest object. This key would then be used again if the client wanted to make further requests for results for the same running query.

  "key" : {
    "uuid": "e244d45c-4086-463b-b1a8-10c8c7d7d6c7"
  },

In v7.2 the query key is now generated by Stroom rather than the client. In the first search request for a query, the client should now omit the key field from the request. Stroom will generate a unique key for the running query and return it in the response. However, in any subsequent requests for that running query, the client should include the key field, using the value from the previous response.

If you have static request JSON files then you can easily remove the key field using jq as follows:

jq 'del(.key)' req.json > req.new.json

4 - Upgrade Notes

Java Version

Stroom v7.2 requires Java v17. Previous versions of Stroom used Java v15 or lower. You will need to upgrade Java on the Stroom and Stroom-Proxy hosts to the latest patch release of Java v17.

Regex Performance Issue in XSLT Processing

v7.2 of Stroom uses a newer version of the Saxon XML processing library. Saxon is used for all pipeline processing. There is a bug in this version of Saxon which means that case insensitive regular expression matching performs very badly, i.e. it can be orders of magnitude slower than a case sensitive regex. This bug has been reported to Saxon and has been fixed but not yet released. It is likely a future release of Stroom will include a new version of Saxon that addresses this issue.

The performance issue will show itself when multiple pipelines with effected XSLTs are being processed concurrently. This impacts XSLT/Xpath functions like matches() that use the i flag for case insensitive matching. If you don’t not use any case-insensitive regular expressions in your XSLTs then you do not need to do anything.

Until Stroom is changed to used a new version of Saxon with a fix, you will have to change the XSLTs that use the i flag in one of the following ways:

• Re-write the regular expression to use case sensitive matching, E.g:
  matches('CATHODE', '^cat.*', 'i') => matches('CATHODE', '^[cC][aA][tT].*')
  This is the preferred option, but may not be possible for all regular expressions.

• Add the flag ;j to force Saxon to use the Java regular expression engine instead of the Saxon one, E.g:
  matches('CATHODE', '^cat.*', 'i') => matches('CATHODE', '^cat.*', 'i;j')
  As this involves changing the regular expression engine it is possible that there will be subtle differences in the behaviour between the Saxon and Java engines. Regular expression engines are notorious for having subtle differences as there is no one standard for regular expressions.

Tagging Entities

As described in Document Tagging Stroom now pre-populates the filter of some of the tree pickers with pre-configured tags to limit the entities returned. If you do nothing then after upgrade these tree pickers will show no matching entities to the user.

You have two options:

1. Tag entities with the pre-configured tags so they are visible in the tree pickers.

   To do this you need to find and tag the following entities:

   • Tag all reference loader pipelines (those using the ReferenceDataFilter pipeline element) with reference-loader (or whatever value(s) is/are set in stroom.ui.referencePipelineSelectorIncludedTags).
   • Tag all extraction pipelines (those using the SearchResultOutputFilter pipeline element) with extraction (or whatever value(s) is/are set in stroom.ui.query.dashboardPipelineSelectorIncludedTags).

   Any new entities matching the above criteria also need to be tagged in this way to ensure users see the correct entities. The new Find Content is useful for tracking down Pipelines that contain a certain element.

   The property stroom.ui.query.viewPipelineSelectorIncludedTags is not an issue for an upgrade to v7.2 as Views did not exist prior to this version. All new dynamic extraction pipeline entities (those using the DynamicSearchResultOutputFilter pipeline element) need to be tagged with dynamic and extraction (or whatever value(s) is/are set in stroom.ui.query.viewPipelineSelectorIncludedTags)

2. Change the system properties to not pre-populate the filters. If you do not want to use this feature then you can just clear the values of the following properties:

   • stroom.ui.query.dashboardPipelineSelectorIncludedTags
   • stroom.ui.query.viewPipelineSelectorIncludedTags
   • stroom.ui.referencePipelineSelectorIncludedTags

Reference Data Store

See Partitioned Reference Data Stores for details of the changes to reference data stores.

No intervention is required on upgrade for this change, this section is for information purposes only, however it is recommended that you take a backup copy of the existing reference data store files before booting the new version of Stroom. To do this, make a copy of the files in the directory specified by stroom.pipeline.referenceData.lmdb.localDir. If there is a problem then you can replace the store with the copy and try again.

Stroom will automatically migrate reference data from the legacy single data store into multiple Feed specific stores. The legacy store exists in the directory configured by stroom.pipeline.referenceData.lmdb.localDir. Each feed specific store will be in a sub-directory with a name like USER-DETAILS-REFERENCE___309e1ca0-7a5f-4f05-847b-b706805d758c (i.e. a file system safe version of the Feed name and the Feed’s UUID .

The migration happens on an as-needed basis. When a lookup is called from an XSLT, if the required reference stream is found to exist in the legacy store then it will be copied into the appropriate Feed specific store (creating the store if required). After being copied, the stream in the legacy store will be marked as available for purge so will get purged on the next run of the job Ref Data Off-heap Store Purge.

When Stroom boots it will delete a legacy store if it is found to be empty, so eventually the legacy store will cease to exist.

Depending on the speed of the local storage used for the reference data stores, the migration of streams and the subsequent purge from the legacy store may slow down processing until all the required migrations have happened. The migration is a trade-off between the additional time it would take to re-load all the reference streams (rather than just copying them from the legacy store) and the dedicated lock on the legacy store that all migrations need to acquire.

If you experience performance problems with reference data migrations or would prefer not to migrate the date then you can simply delete the legacy stores prior to running Stroom v7.2 for the first time. The legacy store can be found in the directory configured by stroom.pipeline.referenceData.lmdb.localDir. Simply delete the files data.mdb and lock.mdb (if present). With the store deleted, stroom will simply load all reference streams as required with no migration.

Database Migrations

When Stroom boots for the first time with a new version it will run any required database migrations to bring the database schema up to the correct version.

On boot, Stroom will ensure that the migrations are only run by a single node in the cluster. This will be the node that reaches that point in the boot process first. All other nodes will wait until that is complete before proceeding with the boot process.

It is recommended however to use a single node to execute the migration. To avoid Stroom starting up and beginning processing you can use the migrage command to just migrate the database and not fully boot Stroom. See migrage command for more details.

Migration Scripts

For information purposes only, the following is a list of all the database migrations that will be run when upgrading from v7.0 to v7.2.0. The migration script files can be viewed at github.com/gchq/stroom .

7.1.0
  stroom-config
    V07_01_00_001__preferences.sql                                 - stroom-config/stroom-config-global-impl-db/src/main/resources/stroom/config/global/impl/db/migration/V07_01_00_001__preferences.sql
  stroom-explorer
    V07_01_00_005__explorer_favourite.sql                          - stroom-explorer/stroom-explorer-impl-db/src/main/resources/stroom/explorer/impl/db/migration/V07_01_00_005__explorer_favourite.sql
  stroom-security
    V07_01_00_001__add_stroom_user_cols.sql                        - stroom-security/stroom-security-impl-db/src/main/resources/stroom/security/impl/db/migration/V07_01_00_001__add_stroom_user_cols.sql
    V07_01_00_002__rename_preferred_username_col.sql               - stroom-security/stroom-security-impl-db/src/main/resources/stroom/security/impl/db/migration/V07_01_00_002__rename_preferred_username_col.sql
7.2.0
  stroom-analytics
    V07_02_00_001__analytics.sql                                   - stroom-analytics/stroom-analytics-impl-db/src/main/resources/stroom/analytics/impl/db/migration/V07_02_00_001__analytics.sql
  stroom-annotation
    V07_02_00_005__annotation_assigned_migration_to_uuid.sql       - stroom-annotation/stroom-annotation-impl-db/src/main/resources/stroom/annotation/impl/db/migration/V07_02_00_005__annotation_assigned_migration_to_uuid.sql
    V07_02_00_010__annotation_entry_assigned_migration_to_uuid.sql - stroom-annotation/stroom-annotation-impl-db/src/main/resources/stroom/annotation/impl/db/migration/V07_02_00_010__annotation_entry_assigned_migration_to_uuid.sql
  stroom-config
    V07_02_00_005__preferences_column_rename.sql                   - stroom-config/stroom-config-global-impl-db/src/main/resources/stroom/config/global/impl/db/migration/V07_02_00_005__preferences_column_rename.sql
  stroom-dashboard
    V07_02_00_005__query_add_owner_uuid.sql                        - stroom-dashboard/stroom-storedquery-impl-db/src/main/resources/stroom/storedquery/impl/db/migration/V07_02_00_005__query_add_owner_uuid.sql
    V07_02_00_006__query_add_uuid.sql                              - stroom-dashboard/stroom-storedquery-impl-db/src/main/resources/stroom/storedquery/impl/db/migration/V07_02_00_006__query_add_uuid.sql
  stroom-explorer
    V07_02_00_005__remove_datasource_tag.sql                       - stroom-explorer/stroom-explorer-impl-db/src/main/resources/stroom/explorer/impl/db/migration/V07_02_00_005__remove_datasource_tag.sql
  stroom-security
    V07_02_00_100__query_add_owners.sql                            - stroom-security/stroom-security-impl-db/src/main/resources/stroom/security/impl/db/migration/V07_02_00_100__query_add_owners.sql
    V07_02_00_101__processor_filter_add_owners.sql                 - stroom-security/stroom-security-impl-db/src/main/resources/stroom/security/impl/db/migration/V07_02_00_101__processor_filter_add_owners.sql

5 - Change Log

For a detailed list of all the changes in v7.2 see: v7.2 CHANGELOG