For HRE creating a separate table and load data

[shussain]

This file is created to deal with a scnerio when deploying to HRE. Currently we have a script to drop the database instance, create a new instance and then run the create_table_and_load_data.psql

However, with the file specifying a DB instance to connect to, our build fails. Hard coding the DB name is problematic for deployment.

As such, I have crated a HRE specific create table and load data script.

[shussain]

@rsanchej please note that if you wish, you can modify your own create_table_and_load_data.psql to import the HRE_create_table_and_load_data.psql so there is no repetition.

E.g the create_table_and_load_data.psql could be

\c cnfadm
\i HRE_create_table_and_load_data.psql 

That way the DRY principle is met.

NOTE: I have not tested the above but it should work

[rsanchej]

Connecting to the database (i.e., \c cnfadm) ensures that the table is created in that specific database. We would not want the table to be created in, say, the default database (i.e., postgres). In MySQL, this is similiar to: use cnfadm. The reason for the repetition is the response to the request of having all databases (and all apps) in the same instance (i.e., DEV and QA).

\c cnfadm
\i HRE_create_table_and_load_data.psql
\c cnfadm-qa
\i HRE_create_table_and_load_data.psql

We should be moving on to separate instances.

[shussain]

One can specify what DB gets the changes applied to it when invoking the script. For example, we have the following as part of the script for deploying the DB:

psql "$DBNAME" -f "$CREATE_LOAD_TABLE_SCRIPT" Where $DBNAME is a parameter (which can be changed depending on what script you want. and CREATE_LOAD_TABLE_SCRIPT="create_table_and_load_data.psql"

The reason for the repetition is the response to the request of having all databases (and all apps) in the same instance (i.e., DEV and QA).

Fair enough. I can see what that would be useful for the development environment. However, it makes deployments for us much harder.

We would like to decouple the rebuilding of the two DBs. And ideally if possible, we would like to decouple the name of the DB since we provide it manually. In addition, our QA DB instance name is different.

---

We should be moving on to separate instances.

I am not too sure I follow what you mean by that. Could you please elaborate?

[rsanchej]

Got it. Can you rename cnfadm to cnfadm-dev to stick to convention and clarify the environments, specially future environments.

What I meant by separate instances refers to coming up with https://java-qa.hres.ca rather than sharing the same application server. I now see that the database instances are not really connected to this other issue.

Thanks.

[shussain]

@rsanchej Regarding renaming the cfngadm DB instance, we can certainly do it. I will create a ticket about that and get @ayoung8's approval

In regards to the pull request, if you don't have any objections, then can you please accept the pull request. Both this PR and PR 8

Regarding using java-qa.hres.ca , that request will have to be routed through @ayoung8 He assigns what VM/server the instances go to

[shussain]

Thank you.

[rsanchej]

Is QA Continuous Integration too? Can you build/deploy QA so that the DB is built? Can you look into MongoDb so that the corresponding DB is cfgDb-qa? So renaming cfgDb to cfgDb-dev would also be appropriate. This is mentioned in mongodb.properties.template like db.properties.template.

[shussain]

Is QA Continuous Integration too? Can you build/deploy QA so that the DB is built?

yes, I have a ticket based on that which Anthony just approved.

I have taken the liberty of creating an issue #9 that has that information