Llibyddap · September 10, 2019 21:38
diff --git a/Noob Guide b/Noob Guide
 Accessing pgAdmin

 The pgAdmin server launches without a connection to the Postgres data base.  In order to connect the admin tool to the app database you'll need to select "Add New Server" under the Quick Links section.  On the Create-Server dialoge box, under the General tab you'll need to provide a "Name".  The name is for pgAdmin user only.  On the second tab titled "Connection" you'll need to provide a "Host name/address".  This Host Name is actually the Docker service and not the actual HTTP address or 'localhost'.  The service name by default installation is "db" but if changed it can be found in the "docker-compose.shared.env.yml" file.  Under "services:" there will be a service related to postgres which by default is db.  As a side note, if you change any of the service names you'll need to be careful to change them throughout the entier docker-compose yml file system.

 The Login Name is "postgres" and the password is your superuser password setup in cookiecutter-config-file.yml.  If you don't remember you can look in the cookiecutter-config-file.yml under "first_superuser_password" where it is stored in plain text.

 Once connected to the database, you can quickly see the underlying data tables by selecting:  Servers -> (db*) --> Databases --> app --> Schemas --> public --> Tables.  From here you can left click on "item" or "user" for a table specfiic menu.  From the Table menue you can selection "View/Edit Data" and "All Rows".  The Data Output should be your user list and on initial launch it should only have your 'first superuser'.

 Data Persistence

 In order to keep the data from session to session it's important to follow a specific order of events [I need to figure out why this is - it seems that the Docker Volumn should persist even if the containers are destroyed - but they don't].  Per the ReadMe documentations, the docker stack is started with `docker-compose up -d` which puts you in development mode (mounted src directories).  If you use `docker-compose down` you'll also destroy the local storage in the `db` service.  However, if you use `docker-compose stop` the containers are stopped but they persist (the data is retained in the container even though it isn't running).  [note - the yml settups all look like they map the data into a volume which shouldn't be contingent upon a container - I would have epxected a volumn named "app-db-data" to be present - it isn't.]
	Accessing pgAdmin

	The pgAdmin server launches without a connection to the Postgres data base. In order to connect the admin tool to the app database you'll need to select "Add New Server" under the Quick Links section. On the Create-Server dialoge box, under the General tab you'll need to provide a "Name". The name is for pgAdmin user only. On the second tab titled "Connection" you'll need to provide a "Host name/address". This Host Name is actually the Docker service and not the actual HTTP address or 'localhost'. The service name by default installation is "db" but if changed it can be found in the "docker-compose.shared.env.yml" file. Under "services:" there will be a service related to postgres which by default is db. As a side note, if you change any of the service names you'll need to be careful to change them throughout the entier docker-compose yml file system.

	The Login Name is "postgres" and the password is your superuser password setup in cookiecutter-config-file.yml. If you don't remember you can look in the cookiecutter-config-file.yml under "first_superuser_password" where it is stored in plain text.

	Once connected to the database, you can quickly see the underlying data tables by selecting: Servers -> (db*) --> Databases --> app --> Schemas --> public --> Tables. From here you can left click on "item" or "user" for a table specfiic menu. From the Table menue you can selection "View/Edit Data" and "All Rows". The Data Output should be your user list and on initial launch it should only have your 'first superuser'.

	Data Persistence

	In order to keep the data from session to session it's important to follow a specific order of events [I need to figure out why this is - it seems that the Docker Volumn should persist even if the containers are destroyed - but they don't]. Per the ReadMe documentations, the docker stack is started with `docker-compose up -d` which puts you in development mode (mounted src directories). If you use `docker-compose down` you'll also destroy the local storage in the `db` service. However, if you use `docker-compose stop` the containers are stopped but they persist (the data is retained in the container even though it isn't running). [note - the yml settups all look like they map the data into a volume which shouldn't be contingent upon a container - I would have epxected a volumn named "app-db-data" to be present - it isn't.]