Skip to content

Modifying demo_config.json

Paul Hodgson edited this page Jun 15, 2018 · 6 revisions

Modifying the demo system behaviour

Contents

  1. Modifying demo_config.json
  2. Changing UND balances and rewards
  3. Modifying DB Template Schemas
  4. Modifying default user permissions
  5. Regenerating Static Resources

Modifying demo_config.json

It is possible to modify some of the configuration options to change how the demo behaves. This section gives an overview of what can be modified in the test/demo_config.json file. The options listed below are considered "safe" configurable items.

We will be using dot notation to refer to specific objects within the JSON, for example:

{
  "demo_apps": {
    "app1": {
      "und_rewards": {
        "user_amt": 1
      }
    }
  }
} 

user_amt will be referenced in the following documentation as demo_apps.app1.und_rewards.user_amt

Important: If you modify any configuration values, it will be necessary to regenerate the static resources (the lookup databases used internally by each app's Haiku Node), otherwise the changes will not take effect, and the demo system will be using stale lookup data.

Changing UND balances and rewards

It's possible to change the starting balance for the demo apps, and the rewards they will pay to users and other apps:

demo_apps.app[n].und_rewards.user_amt

Where N is 1, 2 or 3, representing app1, app2 and app3 respectively.

This will modify how many UNDs app[n] will transfer to each user when data is received

demo_apps.appN.und_rewards.app_amt

Where N is 1, 2 or 3, representing app1, app2 and app3 respectively.

This will modify how many UNDs app[n] will transfer to the providing app when data is received

demo_apps.appN.und_rewards.start_balance

Where N is 1, 2 or 3, representing app1, app2 and app3 respectively.

This will modify how many UNDs the app will be issued when the demo system initialises.

Modifying DB Template Schemas

It is also possible to change the data each app is making available to the Unification ecosystem by modifying the XML schema template:

demo_apps.appN.db_schemas[0].schema

Where N is 1, 2 or 3, representing app1, app2 and app3 respectively.

The Template schema is in XML format, and defines what data an app is making available. This schema is written to the app's smart contract. <field> values can be added/removed to reflect data to be used. The default XML for app1 for example, is:

<schema-template>
    <fields>
        <field>
            <name>account_name</name>
            <type>varchar</type>
            <is-null>false</is-null>
            <table>unification_lookup</table>
        </field>
        <field>
            <name>Heartrate</name>
            <type>int</type>
            <is-null>true</is-null>
            <table>data_1</table>
        </field>
        <field>
            <name>GeoLocation</name>
            <type>int</type>
            <is-null>true</is-null>
            <table>data_1</table>
        </field>
        <field>
            <name>TimeStamp</name>
            <type>int</type>
            <is-null>true</is-null>
            <table>data_1</table>
        </field>
        <field>
            <name>Pulse</name>
            <type>int</type>
            <is-null>true</is-null>
            <table>data_1</table>
        </field>
    </fields>
</schema-template>

So, if we wanted to exclude GeoLocation data from app1's data exports, we just need to remove the <field> element for GeoLocation:

Remove:

<field>
    <name>GeoLocation</name>
    <type>int</type>
    <is-null>true</is-null>
    <table>data_1</table>
</field>

so it becomes:

<schema-template>
    <fields>
        <field>
            <name>account_name</name>
            <type>varchar</type>
            <is-null>false</is-null>
            <table>unification_lookup</table>
        </field>
        <field>
            <name>Heartrate</name>
            <type>int</type>
            <is-null>true</is-null>
            <table>data_1</table>
        </field>
        <field>
            <name>TimeStamp</name>
            <type>int</type>
            <is-null>true</is-null>
            <table>data_1</table>
        </field>
        <field>
            <name>Pulse</name>
            <type>int</type>
            <is-null>true</is-null>
            <table>data_1</table>
        </field>
    </fields>
</schema-template>

Flatten/minify to a single line (remove whitespace and \n), so it becomes:

<schema-template><fields><field><name>account_name</name><type>varchar</type><is-null>false</is-null><table>unification_lookup</table></field><field><name>Heartrate</name><type>int</type><is-null>true</is-null><table>data_1</table></field><field><name>TimeStamp</name><type>int</type><is-null>true</is-null><table>data_1</table></field><field><name>Pulse</name><type>int</type><is-null>true</is-null><table>data_1</table></field></fields></schema-template>

Then copy the value back to demo_apps.app1.db_schemas[0].schema

When the system is next up and running, app1 will only export the Heartrate, Pulse and Timestamp fields.

Modifying default user permissions

It is also possible to modify the default user permissions the demo initialises with, by editing the demo_permissions.permissions object. This is basically a pre-defined list of grant/deny used to pre-populate each app's smart contract. To enable the demo to immediately output data when the haiku CLI is run, most are set to "granted" by default (it get's a little labourious needing to manually grant permissions for every user, each time the composition is brought up!).

Setting all values to false for example, would mean that no apps have been given permission to access any user data when the system is initialised, and you would need to use babel CLI tool, calling the grant function for each user in order to be able to start accessing/exporting data.

Regenerating Static Resources

When the content of demo_config.json is modified, the lookup databases used internally by each app also need to be regenerated, and copied over to the app Docker containers. The simplest way to do this is:

Bring the composition up and open a bash process in the systemtest container:

docker exec -it systemtest /bin/bash

Regenerate the lookup tables:

python create_lookups.py

This should have deleted the current ones, and created new ones.

On the host machine, in the root of the repo, download the lookup databases:

docker cp systemtest:/haiku/test/data/lookups/app1.unification_lookup.db test/data/lookups/app1.unification_lookup.db
docker cp systemtest:/haiku/test/data/lookups/app2.unification_lookup.db test/data/lookups/app2.unification_lookup.db
docker cp systemtest:/haiku/test/data/lookups/app3.unification_lookup.db test/data/lookups/app3.unification_lookup.db
You can’t perform that action at this time.