dGraph Menu
Settings
The settings dialog allows you to view statistics of the current dGraph and set the database connection options. The statistics will inform you of the current number of tables, column, dimensions, and rollups.
The connection information is used as the default settings when refreshing the database and building. You are always prompted to override these settings performing an operation that requires connection information.
Refresh Database
After you have created a dGraph, your database schema may change. If the changes affect your dGraph, the dGraph will need to be refreshed to get the current tables and column settings. When you refresh from the database, all changes will be shown in a change editor that will allow you the option of accepting the changes or canceling the operation. From this screen you can view all of the added, deleted, and updated tables and column between the current dGraph and your current database schema. Keep in mind that dimensions or rollups are based on columns. If a column is removed from the database on which a dimension or rollup is based then the dimension or rollup will be removed from the dGraph as well. Once the changes are accepted the dGraph will update adding, removing, and updating all the tables, column, dimensions, and rollups necessary to synchronize the two schemas.
Verify dGraph
Before a build can be performed, the dGraph must be validated. This is done automatically before a build, but you may also choose to perform this action at any time. Choosing this option will verify the following things.
- A dGraph has a name
- A connection string is specified
- A primary table is defined.
- All tables have unique names
- All columns have unique names
- Ensure all Rollup fields are based on an existing column
- Ensure Rollup fields have unique names
- Sortable fields are valid
- Range dimensions are based on numeric fields
- Date dimensions are based on date fields
- Verify that there is at least one visible field
- Ensure that all tables have exactly one path to the primary table
- Verify that aggregate fields are a valid data type for aggregate function
- Various other internal validation
- Derived fields have unique names
Resolve Duplicate Paths
In other to build the index each table must map back to the primary table along exactly one path. Paths are defined by database relationships. Of course most databases do have cycles in their relationship graphs, so we need a way to define the exact path.
Tools Menu
There are various options available for the application independent of any dGraph.
Options
The options screen allows you to setup global settings for the CQ Studio application. Many database schemas have audit or configuration fields that are never used when searching. If your database has hundreds of table each with three or five fields like this, it can be cumbersome to week through them when configuration fields. In this case you can specify certain field names to never show up in field lists. For example, all tables might have a "ModifiedBy" column which is never used in searches. Just add it to the list of excluded columns and the column will never to displayed in any field list in the Studio application. This is just a convenience to limit the number of fields listed.
View Log
When a build is performed, it is logged. To view the log, choose the Tools menu and then View Log. In the log you can view each build, its status, time built, and filename of the defining dGraph.
Generate API
You can actually generate a strongly-typed API based on your dGraph schema. This enables you to access your objects by name and get Visual Studio Intellisense. You can effectively eliminate run-time error because of loosely-typed objects. Reference your objects and fields by name.
