Release Notes

Release Notes

2.3

Upgraded axios version due to vulnerability

Added docker-compose to create test database with Postgres and Hasura containers

2.2

Function tracking

In this release we have introduced tracking/untracking of custom functions. The default behavior is to track all functions in the target schema. The configuration can comprise a key which will enable filtering of the functions to track in case a common naming method is applied to the functions that are required to be tracked.

functionAndClause - This can be used by setting the value to AND functions.routine_name... The AND clause is appended to the SQL used to retrieve a list of functions from the information_schema.

Refer to the Hasura documentation on function tracking. Errors are raised if tracking is attempt on any function not returning a 'COMPOSITE' type.

Relationship naming

In the latest release of Hasura we noted improvements to relationship names. We have advanced relationship naming options which it is possibly better to refer to the source code to understand.

A simple example is:

if (!config.operations) {
    config.operations = {};
    config.operations.untrack = true;
    config.operations.trackTables = true;
    config.operations.trackRelationships = true;
    config.operations.trackFunctions = true;
}

const hat = new HasuraAutoTracker();
hat.UseCompactRelationshipNaming(config);

In this example the UseCompactRelationshipNamingmethod injects functions into the configuration which are used to provide relationship names. CompactRelationNaming converts foreign_key_name to foreignKeyName style and renames customers to customer.

With the example database included in the source, it is possible to build queries with notation like: { hasura_test_customers { customerName: name devices { deviceName: name } } }

Here devices is used rather than customer_devices or devicesBycustomer etc.

This behavior can be completely overridden by injecting function names into the configuration:

Default naming can be applied as follows:

const hat = new HasuraAutoTracker();
hat.UseDefaultRelationshipNaming(config);

Defaultnaming is applied in the absence of any functions being provided in the config.

Refer to index.js and note the following where, if no functions are provided in the config, the default naming functions are applied.

  if (!config.getArrayRelationshipName) {
        config.getArrayRelationshipName = this.defaultArrayRelationshipName;
   }

  if (!config.getObjectRelationshipName) {
       config.getObjectRelationshipName = this.defaultObjectRelationshipName;
  }

Minor changes

• Improvements to log output formatting have been made to ease readability of trace information

• Restructuring of the code is underway, but at the moment the focus is on minimizing dependencies and avoid sprawling code spread across too many files. Consideration is being given as to how to best refactor the current code base to improve maintainability.

Sample Database

The sample database, which can be created using SQL execution in the Hasura UI, has been extended to include a device type to demonstrate compact relationship naming, and to make the data slightly richer for example use.

2.1

In this release we have provided an example of using the custom relationship names and suggest using the two example functions provided in run_hat.js (refer example code). The functions attempt to create a succinct name for each array or object relationship. The methodology used is straight-forward and referring to the code will be easier than a verbous explanation here.

We have implemented the Hasura admin secret to use secure connections during the auto-configuration process.

This release also introduces a check to ensure the target schema exists, which is useful in the continuous integration process to ensure database setup has been completed.

2.0.1

Users requested the ability to create standard views which can be tracked, i.e. the need for JSON values to be exposed in the view is not always a requirement. The columns node has been made optional to facilitate this use case.

The relationships node in a view specification is also optional, as not all views with have relationships to other database entities.

2.0.0

Major internal reworking of the configuration workflow to enable the CLI to execute tasks in isolation of each other, e.g. untrack tables as a separate operation from tracking tables, views and relationships.

Dropped internal use of async methods.

1.6.5

Key achievements:

New configuration sections to enable bulk SQL script execution

This feature may prove useful to:

• Create functions required by the additional views built from the scripts section
• Generate test data
• Automate database tasks after a build has occurred

The new scripts section comprises a beforeViews and afterViews section as indicated below...

{
    "hasuraEndpoint": "http://localhost:4010/v1/query",
    "targetSchema": "hasura_test",
    "primaryKeySuffix": "Id",
    "logOutput": true,
    "scripts": {
        // An array of filenames - SQL scripts to be executed in the specified sequence
        // These scripts will be executed before additional views are created
        "beforeViews": [
            {
                "source": "./example/beforeViews.sql"
            }
        ],

        // An array of filenames - SQL scripts to be executed in the specified sequence
        // These scripts will be executed after additional views are created
        "afterViews": [
            {
                "source": "./example/afterViews.sql"
            }
        ]
    },
    "views"...
}

1.6.3

Key achievements:

• Stabilise the code for automatic table and view tracking
• Support automatic and custom naming of relationships
• Enable creation of custom views and automatic creation of relationships between custom views and other database entities
• Add a CLI