Database Schema and Views Reference Guide › Database Views › Primary Views Definitions › Naming Convention › View Stacks

View Stacks

The view stacks detail what additional views and tables are referenced under the primary views. Each view stack looks similar to this:

This is common to most of the primary views. The Primary view points to another underlying view. This view points to a view, which in most case references a view with almost the same name but with an integer number (m) inserted, such as WGN_V_1_EVENT_2.

There is no significance to what RLS model the number m represents, although these details are stored internally, and is purely based on the order in which RLS model are created. The exception to this is for m=1. This is always the default model that has been set up.

In addition to these views will be a set of views that end in _RLS_n. These are identical to the m=1 views and were the view used by previous version of CA DataMinder. These views should be ignored as they will be deprecated at some point in the future. This view points to one of six views, usually given the same name as the top level view but with an additional _MD_, _MDX_, _MS_, _MSX_,_PD_, _PDX appended after the _V part of the name. Which one of these is dependent on which RLS model that is relevant.

For the purposes of this document the default model will be used _MD_ will be used as an example in most case, however for some views the _PD_ model will be used to demonstrate how this is applied particularly when the _MD_ simply points to the underlying table (such as no RLS is applied to the trigger view for any for the management group models. There are also 2 other sub-level view types: WGN_V_AD_... is the administrator view; and WGN_V_CM_... is an additional sub level that contains common views which do not apply RLS and are common across all models. These lower level views contain much of the detail of what and how data is returned. It contains tables, highlighted in italics, and additional views, which in turn reference additional tables.

It is important to note that these view stacks should not be taken as an exact reflection of what may be found in customer environments. This will change some of the underlying tables and views depending on which security model is used. Also from time to time the actual views may change, particularly the lower levels views, due to a schema change or a performance enhancement.

If searches are written using these primary views, any changes to underlying views should have no effect on the results returned. The only effect that would occur may be that the search may return results more quickly due to a performance improvement to an underlying view. If a schema change takes place it may be that additional views are included. Although a search should not fail using the old views it may be beneficial to change the search to use the new views, as it may improve performance and would guard any possible future deprecation of old views.

The table contains brief descriptions of the columns. For further details of see the Database Schema document.

Provided a user has the administrative privilege 'Admin: Disable Security Group Filtering' disabled, all views described below will have RLS applied with the exceptions of:

WGN_V_PARTPNTUSER_1

WGN_V_QUARANTINE_EVENT_1

WGN_V_GROUP_HIST_1

WGN_V_GROUP_HIST_2

WGN_V_CURR_PROP_VAL_1

WGN3USERADDRESS

WGN_V_USER_ADDRESS_1

WGN_V_ADDRESS_1

WGN_V_INTPARTPNTUSER_1

If using any of these views, RLS should be applied by an appropriate join to one of the other views.