Added an optional DB connector file to standardize the connections from the app to PGO.

[ahron1]

The purpose of the optional DB Connector is to have a standard interface for the rest of the app to communicate with PGO. This will make it easy to reflect any changes in the return type of PGO (e.g. when it moved from returning tuples to maps). Or to replace another tool with PGO, or vice versa. So the app calls functions defined in a "helper" file. And the helper file communicates with PGO via the connector. So in case of any changes with PGO, only this connector file needs to be updated, and not every pgo:query call.

[tsloughter]

I'm not sure about this, esp not having having the pgo_ prefix to "namespace" it.

[ahron1]

Yes, this is the part the application uses to interface with pgo. Basically the idea is that from the PoV of the application, any PostgreSQL interface is a drop-in replacement. Just pass the query and params.

It is this file that the dev team has to tweak if they switch to another connector. The core app code can thus remain untouched.

[abxy]

@ahron1: Wouldn't it make more sense to keep the db_connector module in your own application? That way you are free to alter the implementation to suit your needs, including switching the underlying database driver. By putting it in pgo you're effectively handing control of the interface to someone else, in a way it's equivalent to targeting the pgo API directly.

[ahron1]

It is like saying to the user - you don't have to be locked-in if you try out pgo. Because if the entire codebase uses pgo calls, it is a sort of lock-in, in the sense that switching to an alternative will need multiple changes.

You are right that ideally it should be in the application. But many people just call pgo directly. So this is also a way of ensuring good coding practice by users.