Skip to content

Expose node-postgres (pg module) directly on the connector #200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

zero5100
Copy link

Description

The problem we ran across is that brianc/node-postgres parses the PG DATE type into JavaScript Dates by default instead of strings. To me, this doesn't make much sense since JS doesn't have a date-only type, but it what they decided to go with. They provide the ability to change how the values are parsed for each PG data type using types.setTypeParser (see related issue), but as far as I can tell there is no easy way to change the parser on the pg module instance that the loopback connector is using.

To make things easier from our end we configured our date model property as a String so that we can easily and accurately save dates in string form. (e.g. { exampleDate: '2016-12-20' }).

"exampleDate": {
  "type": "String",
  "required": true,
  "length": null,
  "precision": null,
  "scale": null,
  "postgresql": {
    "columnName": "example_date",
    "dataType": "date",
    "dataLength": null,
    "dataPrecision": null,
    "dataScale": null,
    "nullable": "NO"
  }
}

The problem then is that we still get dates back from the ORM as JS Dates (e.g. Tue Dec 20 2016 00:00:00 GMT-0600 (CST)). This technically has the correct date portion, but when formatting it as a string there is the potential for the day to shift forward or backward because of the time in regard to the time zone if care isn't taken. If the date that was returned was Tue Dec 19 2016 18:00:00 GMT-0600 (CST) instead it may be manageable since it is technically the same point in time as the date string of '2016-12-20' (assumed to be at midnight UTC), but the way it currently works is dangerous in our case. This is for a financial system so there needs to be as small of room for error as possible.

By exposing the pg instance as "postgresql" on the connector, we are able to configure the type parser in our application like so.

(server.js or wherever)

var pgDs = app.datasources.PG_DB;
if (pgDs && pgDs.connector && pgDs.connector.postgresql) {

  // Parse the postgres DATE type as a string instead of a date
  pgDs.connector.postgresql.types.setTypeParser(1082, function(val) { return String(val) });
}

I am sure there is a better way to accomplish this so I am open to feedback for other ways to solve this issue. I would be up for contributing some sort of parser configuration system if there was interest in it. This fix got us going but there may be concerns with exposing the pg instance to the application that I am not aware of.

Thanks in advance.

Related issues

(Parsing dates as strings over on the pg module issues)
brianc/node-postgres#285

Checklist

  • New tests added or existing tests modified to cover all changes
  • Code conforms with the style
    guide

@slnode
Copy link

slnode commented Jan 12, 2017

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@slnode
Copy link

slnode commented Jan 12, 2017

Can one of the admins verify this patch?

2 similar comments
@slnode
Copy link

slnode commented Jan 12, 2017

Can one of the admins verify this patch?

@slnode
Copy link

slnode commented Jan 12, 2017

Can one of the admins verify this patch?

@ssh24
Copy link
Contributor

ssh24 commented Mar 7, 2017

@zero5100 Could you please your branch?

@ssh24
Copy link
Contributor

ssh24 commented Mar 28, 2017

@slnode ok to test

@ssh24
Copy link
Contributor

ssh24 commented Mar 28, 2017

@zero5100 I have rebased the branch for you. Could you please add some unit tests to go with the fix?

@zero5100
Copy link
Author

@ssh24 Thank you. I can create a simple test that just makes sure that the newly exposed object is defined. Which test file should it go in?

@ssh24
Copy link
Contributor

ssh24 commented Mar 31, 2017

@stale stale bot added the stale label Aug 22, 2017
@stale
Copy link

stale bot commented Aug 22, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot closed this Sep 5, 2017
@0candy 0candy removed the review label Sep 5, 2017
@stale
Copy link

stale bot commented Sep 5, 2017

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants