Google OAuth + Postgresql fails due to insufficient field size

[justinlindh]

Using this component, alongside the passport-google-oauth module with a Postgresql datastore fails with the following error:

error: value too long for type character varying(1024)
    at Connection.parseE (.../node_modules/loopback-connector-postgresql/node_modules/pg/lib/connection.js:534:11)
    at Connection.parseMessage (.../node_modules/loopback-connector-postgresql/node_modules/pg/lib/connection.js:361:17)
    at Socket.<anonymous> (.../node_modules/loopback-connector-postgresql/node_modules/pg/lib/connection.js:105:22)
    at Socket.emit (events.js:107:17)
    at readableAddChunk (_stream_readable.js:163:16)
    at Socket.Readable.push (_stream_readable.js:126:10)
    at TCP.onread (net.js:538:20)

Using memory datastore succeeds.

I've narrowed it down to the UserIdentity model. It's likely the "profile" field, which is of type "Object" in the model and apparently creates a postgresql column of type: character varying(1024)

As such, I don't know whether this issue is better suited to the postgresql connector not assigning a better data type to the column, or whether it's better handled here (I'm new to loopback).

[justinlindh]

The following may solve the issue (I've only tested that it's writing to the db correctly, haven't gotten far enough into my implementation to see whether there's problems downstream with this):

user-identity.json

    "profile": {
      "type": "Object",
      "postgresql": {
        "dataType": "text",
        "nullable": "NO"
      }
    },

(Of course, another valid workaround is to extend off of this base model and override the "profile" with that datasource definition... maybe that's the intended design for this component and I just didn't realize it)

[loay]

Hi @justinlindh
What version of npm and node are you using?
I tested these components with npm 3.3.9 and node 4.x as well as installed loopback@2 and it works fine on my end.
The only issue I got was the loopback version so I installed loopback@2 then tested and it is went through fine.
If you are still having these issues, please let me know. Thanks.

[justinlindh]

Reproducing the problem likely depends on how much data is being returned in the profile field. It's possible that minimal profiles won't trigger the problem. I realize that makes this significantly more difficult to reproduce, but another check could be directly against the datastore: if it's creating the profile column in postgresq is still being created as varchar(1024), it's likely still an issue.

I haven't tried to reproduce this lately. I'll try to do that as soon as I get a chance; there's a possibility that this has been resolved elsewhere, or handled better (maybe truncating the profile data prior to inserting).

[tkaplan]

Any update on this issue? I'm having issues saving manyEmbedded model in postgresql because it looks like it serializes to varchar. I could change the db manually, but I prefer not to. Where would I put the following in the relationship for embedded model:

postgresql: {dataType: "text"}

[taras]

I encountered the same problem with GitHub profiles.

[taras]

I was able to overcome the problem by extending the built in UserIdentity model and overloading the profile property definition

{
  "name": "userIdentity",
  "plural": "userIdentities",
  "base": "UserIdentity",
  "properties": {
    "profile": {
      "type": "Object",
      "postgresql": {
        "columnName": "profile",
        "dataType": "character varying",
        "dataLength": 10000
      }
    }
  },
  "validations": [],
  "relations": {
    "user": {
      "type": "belongsTo",
      "model": "user",
      "foreignKey": "userId"
    }
  },
  "acls": [],
  "methods": []
}

[loay]

Hi @tkaplan
Does @taras fix work for you? If not, please let me know and I will see what we can do about it.

[davidcheung]

It looks like this PR addresses this issue, the field is mapped as TEXT now https://github.com/strongloop/loopback-connector-postgresql/blob/ff75c74ece50b900f18ed4d027ac4ffa82728f02/lib/migration.js#L530

/cc @loay

[loay]

Hi @justinlindh It looks like the issue is fixed as per the PR mentioned in the previous comment.
Can you please confirm? Thanks.

[justinlindh]

Yeah, this has been resolved.