Unify property names

[cookersjs]

Steps using release-common-lib to get the DB adaptor properties utilize different property names than the typical release pipeline.

I propose that the 'getMySQLAdaptorFromProperties' method be expanded upon so that there can be retrieval from curator or release databases. Perhaps getMySQLAdaptorFromProperties should have default behaviour for the release variable names (since it is a part of release-common-lib) and then maybe add in a new method getCuratorMySQLAdaptorFromProperties.

Thoughts? @SolomonShorser-OICR @jweiser

[SolomonShorser-OICR]

What are the mismatches in property names? Perhaps the programs that use release-common-lib should conform to release-common-lib's preferred names.

[jweiser]

Since the getMySQLAdaptorFromProperties method assumes a prefix of "db." followed by universal db properties such as "user", "pass", "host", "name", and "port", maybe we can have a generic method that takes an additional parameter of String propertyPrefix (in addition to the properties object). Then we could have other convenience methods for that call this generic method with common prefixes such as"db.", "curator.", etc.

We could make the generic method private if there are only a small number of different prefixes, but if we really need to we could expose the generic method that allows the caller to provide any prefix they want (though, it's probably better to standardize the property names for things like "curator", "release", etc. and just have the specific/convenience methods with one each for getting a release DBA, curator DBA, etc).

[SolomonShorser-OICR]

Programmatically adding a prefix to a property in a way that the user might know or expect allows the possibility that the property will be used in ways the user never planned.

Why not just document the properties that release-common-lib expects, and require users of the library to conform to that if they want their properties to be used?

[cookersjs]

What are the mismatches in property names? Perhaps the programs that use release-common-lib should conform to release-common-lib's preferred names.

Why not just document the properties that release-common-lib expects, and require users of the library to conform to that if they want their properties to be used?

Kind of all arguing for the same thing, but I think the problem with adhering to the existing 'release-common-lib' property names is that they are generic (db.host, db.user, db.name). For steps that interact with both the release and curator databases, there isn't any way to specify two entirely separate databases/hosts/credentials to create MySQLAdaptors for.

As a compromise, what if the getMySQLAdaptorFromProperties method took in a 'type' argument as well that could be either 'curator' or 'release' (and even 'graph' in future iterations if we changed the method name to getDBAdaptorFromProperties). With that argument, the method could just shunt the adaptor creation to an appropriate function.

One additional thing to address is that the 'db.name' property complicates this matter further -- not only can you have a 'curator' and 'release' db adaptor, but within release there will be different DBs that need to be accessed (test_slice, release_current, release_previous) at different times. Thoughts, @SolomonShorser-OICR , @jweiser ?

[jweiser]

Since we have fixed relational database names that need to be accessed as part of the release process, what if we just provide pubilc methods in release-common-lib for things like:

• getReleaseCurrentDBA
• getReleasePreviousDBA
• getGKCentralDBA
• etc.

We can then just consolidate any common logic in private methods so the details are hidden and free to change as necessary,