From the postgres terminal download the schema file dbcreate.sql (modified file of original RasaUI database).

postgresTerminal:~$ wget https://raw.githubusercontent.com/biddy1618/rasa-crud/develop/crudRasa/static/dbcreate.sql

Then create the database by running the downloaded script.

The configuration file of Postgres Server is at /etc/postgresql/9.5/main/postgresql.conf. If you want to change the default timezone of the server, then you should change the postgresql.conf file line with timezone = 'timezone', where timezone is chose from list https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.

If you want to change the default timezone of one specific database then you should enter the server's psql termnail as administrator and type the following:

ALTER DATABASE 'some_database' SET TIME ZONE 'timezone';

SELECT pg_reload_conf();

User for postgres service is created as postgres, and in order to enter the local server you need to switch to that user sudo -i -u postgres

.env file holds environment variables to be exported. These are loaded when app starts through script in app.py file.

from dotenv import load_dotenv
load_dotenv()

Request should have header with key Authorization that will contain token. Before any request to database, check if token is valid.

One can view the status of implementations of endpoints in Google docs.

app.py - sets up the Flask server along with SQLAlchemy settings.

config.py - holds the deployment settings for the Flask server. In order to change the deployment settings change the .env file for corresponding setting in config.py.

run.py - main script to run in order the start the server.

migration folder - holds scripts for migrating data from DialogFlow to Rasa.

orm folder - holds ORM models for the database. models.Helper class implements serialization of the ORM results into JSON format, also implements the update operation for ORM models.

routes folder - holds the implementation of endpoint routes for the CRUD operations.

static folder - holds static files.

Very basic tutorial on Docker is here

Also check out this post regarding removal of containers, images, docker objects, etc.

Very good reference to Docker commands in this Medium post

• docker images -a - list all images.
• docker ps -a - list all containers.
• docker system prune - remove all stopped containers, all dangling images, and all unused networks.
• docker exec -ti CONTAINER /bin/bash - start Unix shell in the container.
• docker image|container rm IMAGE_ID|CONTAINER_ID - remove image or container.
• docker build -t name:tag . - to build image from Dockerfile.
• docker run -p DOCKER_HOST_PORT:CONTAINER_PORT name:tag - run container. -p (--publish) to publish container's port to the host, -d (--detach) to run container in background.

One should add option -y to automatically asnwer yes to prompt while runnnig shell commands and also merge RUN ... commands into one, i.e. in Dockerfile

...
RUN apt-get update &&\
    apt-get install --yes python-dev graphviz libgraphviz-dev pkg-config &&\
    pip install -r requirements.txt
...

To set the correct client.

export AWS_PROFILE=k8s.watcher
export KUBECONFIG=~/config

kubectl get pods -n dev-rasa - to get the list of hosted services

kubectl logs -f NAME -n dev-rasa - to view live the logs of service

Go to codepen.io and run the cors-check script to test the CORS functionality

One can't do ORM operations with sqlalchemy.Table.

One cannot use the Table objects to do proper ORM. When user queries a Table object (via session.query(query)) he/she will get the results returned to you as read-only namedtuple-like objects. Setting their attributes makes no sense this way makes no sense.

Alter the database, so that Settings table has a primary key. Tables need to have primary key in order to map a particular table.

The SQLAlchemy ORM, in order to map to a particular table, needs there to be at least one column denoted as a primary key column; multiple-column, i.e. composite, primary keys are of course entirely feasible as well. These columns do not need to be actually known to the database as primary key columns, though it’s a good idea that they are. It’s only necessary that the columns behave as a primary key does, e.g. as a unique and not nullable identifier for a row.

Most ORMs require that objects have some kind of primary key defined because the object in memory must correspond to a uniquely identifiable row in the database table; at the very least, this allows the object can be targeted for UPDATE and DELETE statements which will affect only that object’s row and no other. However, the importance of the primary key goes far beyond that. In SQLAlchemy, all ORM-mapped objects are at all times linked uniquely within a Session to their specific database row using a pattern called the identity map, a pattern that’s central to the unit of work system employed by SQLAlchemy, and is also key to the most common (and not-so-common) patterns of ORM usage.

Note:

It’s important to note that we’re only talking about the SQLAlchemy ORM; an application which builds on Core and deals only with Table objects, select() constructs and the like, does not need any primary key to be present on or associated with a table in any way (though again, in SQL, all tables should really have some kind of primary key, lest you need to actually update or delete specific rows).

TESTING POSTGRES:

To allow remote connections to PostgreSQL server, change the line in file /etc/postgresql/9.5/main/postgresql.conf:

listen_addresses = 'localhost' to listen_addresses = '*'

and add entry in file /etc/postgresql/9.5/main/pg_hba.conf:

# TYPE  DATABASE        USER    CIDR-ADDRESS    METHOD
local   all     all     md5
host    all     all     0.0.0.0/0       md5

GIT Commands

In order to pull the last changes, but retain local changes (there may be conflicts), do the following:

git stash
git pull
git stash pop

• Fix all inserts related to JSON column.
• Alter the database declaration so that tables intents and actions have unique names. Also table reponses should have unique intent_id, action_id, buttons_info, response_text, and table expressions should have unqiue intent_id and epxression_text.

Responses

• Intent can have several responses, for instance in domain.yml file:

...
templates:
  utter_greet:
    - text: "hey there {name}!"  # {name} will be filled by slot (same name) or by custom action
  utter_channel:
    - text: "this is a default channel"
    - text: "you're talking to me on slack!"  # if you define channel-specific utterances, the bot will pick
      channel: "slack"                        # from those when talking on that specific channel
  utter_goodbye:
    - text: "goodbye 😢"   # multiple templates - bot will randomly pick one of them
    - text: "bye bye 😢"
  utter_default:   # utterance sent by action_default_fallback
    - text: "sorry, I didn't get that, can you rephrase it?"
...