Timeline History

Timeline History can be found by selecting Details for any VDB located on the VDB List page and then selecting the Timeline History tab. This view serves as a developer-centric console that shows the complete history of a VDB, including non-active timelines, which contain information like past test results. It allows developers to curate and access the complete chronology of their testing efforts with operations like renaming individual timeflows, make active, refresh to snapshot, and create bookmark to drive organization and access.

Timeline History UI

The Timeline History UI is comprised of a vertical timeline-based representation of all actionable points of interest (snapshots) for that VDB. The snapshot list is chronologically grouped over blocks of time to easily identify relevant snapshots to act upon. Once the right snapshot is found, users can access a contextualized action menu by selecting the corresponding ellipsis to the relevant snapshot.

In the latest version of Data Control Tower (DCT 16.0.0), several key fields have been introduced to enhance data traceability and context understanding.

Origin Source: Identifies the top-most parent (dSource) from which the data originated, and clicking on this field redirects users to the origin source’s Detail Page for comprehensive insights.
Origin Timeline Location: Specifies the exact moment in time on the origin source timeline where this data was derived.
Parent Source: Denotes the immediate parent source of the data, with a click-through feature leading to the parent source Detail Page.
Parent Timeline Location: Pinpoints the precise moment in time on the direct parent's timeline from which the data originated, further solidifying the data's lineage and accessibility.

Non-active timelines

Non-active timelines (previously, “timeflows”) are a critical aspect to data virtualization, in addition to being an important tool for developers. Whenever a time-based operation takes place, the previous timeline (and associated data) becomes non-active, and a fresh timeline takes its place.

Non-active timeline creation from self-refresh

In this example, a developer has performed a self-refresh (previously, “rewind” or “rollback”). In refreshing Snapshot B, the developer has created a new active timeline that represents a clean slate starting with the data state of Snapshot B. If the developer wants to refer back to the past results, represented on the non-active timeline, they can activate the past timeline by hitting the Make Active button in the DCT UI, or by refreshing to a point in time by referencing the non-active timeline’s ID.

For developers, having the ability to catalog (name and tag) and reference past timelines is a critical aspect of application development such as performing ad hoc code validation or manual testing. The Timeline History UI in DCT provides a home for single VDB visibility of all accessible timelines (note: timeline availability is controlled through capacity management and snapshot retention policies).

Time concepts within the Timeline History tab

DCT’s UI highlights different notions of time within Delphix (e.g. dSource, VDB, and VDB lineages) and how they relate to one another. These time-based relationships are exposed in the Timeline History view to drive accurate testing for developers.

The “Based on dSource time” designation helps to drive awareness of the relationship between a VDB and its dSource provision point (in most cases this will equate to the production database’s state at that time), which is helpful for use cases such as capturing data from a meaningful event. As a VDB refreshes to newer snapshots on a dSource, those changes of data state are grouped separately on the Timeline History view as they represent completely different data.

Timeline operations

To reference another timeline, like one from the past, select it and use the Make Active button. This would make the timeline active, so that the data therein can be accessed.

Refresh to snapshot

Included within each timeflow are snapshots that can be accessed via a dropdown menu under each timeflow. If given the right permission, a developer can refresh the VDB to that snapshot. While this may seem similar to Make Active, there are underlying differences; a refresh will reprovision the VDB based on that point in time, whereas, Make Active simply changes the reference to different blocks of the underlying storage.

Create bookmark

A snapshot allows developers to convert it into a DCT Bookmark, which enables them to assign a name and special retention policy to that time reference. This also enables stronger collaboration between developers, as bookmark references can be used for a sibling refresh operation.

Rename timeline

Curate timelines to correspond with tests by renaming them to easily reference the resulted data. This action can be performed by clicking the ellipsis on the timeline to reach a drop-down menu. This menu includes the option to rename which will open a dialog box to input a new name. The input is prefilled with the current timeline name by default. The changes may take a short time to be reflected in the UI.

Delete timeline

Delete timelines via the UI by selecting the ellipsis next to the corresponding timeline and selecting delete. When clicked, this opens a confirmation dialog. Once confirmed, a job is kicked off to delete the timeline. This menu item is disabled for the currently-active timeflow.

API documentation

While the DCT UI provides a visual aspect to timeflow chronology and grouping, the DCT API has all of the necessary instrumentation to integrate these concepts into automation. The formal documentation can be found via DCT's Swagger docs or the Developer resources documentation section. This portion of the timeline documentation will provide some general examples:

Get a list of a VDB's timelines

This simple call will enable the listing of the entire timeflow roster underneath a VDB enabling a developer to take inventory and action.

NONE

curl -X 'POST' \
  'https://<APPLIANCE_ADDRESS>/v3/timeflows/search?limit=50&sort=id' \
  -H 'accept: application/json' \
  -H 'Authorization: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{
  "filter_expression": "dataset_id eq '\''1-ORACLE_DB_CONTAINER-2'\''"
}'

The UPDATE timeflow API can be used to change a timeflow's name

Once the appropriate timeflow is found, developers can rename the timeflow to align with a naming scheme or other relevant designations such as a compatible code branch.

NONE

curl -X 'PATCH' \
  'https://<APPLIANCE_ADDRESS>/v3/timeflows/1-ORACLE_TIMEFLOW-7' \
  -H 'accept: application/json' \
  -H 'Authorization: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{
  "name": "Latest on refresh state"
}'

List all the snapshots for a timeflow

Developers can then use the snapshot API to find all relevant "actionable" points in time on the identified timeflow. The below example shows how to only expose snapshots on a particular timeflow. From there, developers can feed the relevant snapshot ID into refresh or provision endpoints or create a bookmark reference from that snapshot.

NONE

curl -X 'POST' \
  'https://<APPLIANCE_ADDRESS>/v3/snapshots/search?limit=50&sort=id' \
  -H 'accept: application/json' \
  -H 'Authorization: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{
  "filter_expression": "timeflow_id eq '\''1-ORACLE_TIMEFLOW-7'\''"
}'