Update a WHPM table

PATCH {{baseUrl}}/api/model/tables/:tableId?showFilterTokens=true&showExpressionAs=tree

This API updates a detailed definition for a specified (logical) table in the changeset.

For a normal logical table or a warehouse partition mapping table, you can update the following: the logical table name in the information field, isTrueKey, logicalSize, isLogicalSizeLocked, primaryDatasource, secondaryDatasource field, prompt ids in sapHanaParameters field, physical table object name, physical table name, and the table prefix in physicalTable field. When the primaryDatasource or secondaryDatasource of this logical table is updated, the related primaryDatasource or secondaryDatasource of all other logical tables that share the same physical table with this logical table are updated.

For a freeform SQL table, you can update the following: the logical table name in the information field, isTrueKey, logicalSize, isLogicalSizeLocked, primaryDatasource, encloseSqlInParentheses field, physical table object name, sqlStatement, and columns in physicalTable field. The primaryDatasource change will not affect other logical tables that share the same physical table with this logical table.

For a metadata partition mapping table, you can update the logical table name in the information field, logicalSize, isLogicalSizeLocked, partition base tables and their partition filters in partitionTables field.

For all kinds of tables, the table name cannot be duplicated within the project.

The response contains the updated definition and specific field information of the logical table.

A changeset ID is required to execute the request and can be obtained using the changeset creation API. An authorization token is required to execute the request and can be obtained using Authentication endpoints.

To update the detailed definition for the specified table to metadata, commit using the POST /model/{changesetId}/commit API.

Request Params

• reuse_any: Updates the column data type to use the most recent column definition. In the example above, the column data type for C1 is changed to char(4) since Table2 was added after Table1.
• reuse_compatible_data_type: Updates the column data type to use the data type with the largest precision or scale. In the example above, the column data type for C1 is changed to char(4), as defined in Table2.
• reuse_matched_data_type: Renames the column in newly added table to allow it to have different data types. In the example above, column C1 uses char(1) for Table1. Column C1 in Table2 is defined as a separate copy of C1 and uses char(4). This option can cause unwanted schema changes and should be used only when necessary.

If this value is not set, use the option that set on DBRole catalog setting. | | fields | null | | A comma-separated, top-level field whitelist that allows the client to selectively retrieve part of the response model. By default, all fields are returned. If specified, extra filtering is applied, and for the top-level object (if the root model is an array, each array element), only the listed fields are kept in the response. For example, "information,logicalSize" keeps only the "information" and "logicalSize" fields, omitting all other fields in the top-level response model. | | showFilterTokens | boolean | | Specify whether "qualification" is returned in "tokens" format, along with "text" and "tree" formats. A filter's "qualification" is presented in the following formats:

• "text": A human readable, but non-parsable text, describing a filter's qualification.

• "tree": A tree data structure fully defining the filter's qualification.

• "tokens": A list of parsed tokens that define a filter's qualification. Be aware that generating tokens requires additional time. If omitted or false, only "text" and "tree" formats are returned. If true, all "text", "tree" and "tokens" formats are returned. | | showExpressionAs | string | | This parameter specifies the format in which the expressions are returned in response. This parameter applies to the expressions in a fact or attribute and custom expressions used in a filter, prompt, security filter, custom group, etc. Expressions are presented in the following formats:

• "text": A human readable, but non-parsable text, describing the expression. This is the default format that is always returned in the response.

• "tree": A tree data structure fully defining the expression. This format can be used if you want to examine and modify the expression programmatically.

• "tokens": A list of parsed tokens. This format can be used if you want to examine and modify the expression using the parser component. Note that generating tokens requires additional time.

  Tokens are a semi-structured representation of MicroStrategy expression text that includes object references. For example, let’s say a filter expression is "Revenue > Cost". When the filter expression is represented as tokens, the text is broken down into pieces (tokens) with information about what these pieces represent in the metadata: ("Revenue", Revenue_ID), (">", GreaterThan_ID), ("Cost", Cost_ID). If omitted, the expression is returned in "text" format. If tree, the expression is returned in "text" and "tree" formats. If tokens, the expression is returned in "text" and "tokens" formats. |

Request Body

{"information"=>{"name"=>"Updated WHPM Table"}, "logicalSize"=>10, "isLogicalSizeLocked"=>true, "partitionLevel"=>[{"objectId"=>"8D679D4A11D3E4981000E787EC6DE8A4", "subType"=>"attribute", "name"=>"Quarter"}]}

HEADERS