Column is always integer when running `npm run migrate`

[dhmlau]

Description / Steps to reproduce / Feature proposal

I have a model property of type string. After running npm run migrate, the table gets created, and the type shows integer.

• I'm using postgresql (not sure if it makes a difference)
• my model ts looks like:

import {Entity, model, property} from '@loopback/repository';

@model()
export class Customer extends Entity {
  @property({
    type: 'string',
    id: true,
    generated: true,
  })
  custid: string;

  @property({
    type: 'string',
    required: true,
  })
  custname: string;

  constructor(data?: Partial<Customer>) {
    super(data);
  }
}

Running \d customer on postgresql, it shows:

testdb=# \d customer
                               Table "public.customer"
  Column  |  Type   | Collation | Nullable |                 Default                  
----------+---------+-----------+----------+------------------------------------------
 custid   | integer |           | not null | nextval('customer_custid_seq'::regclass)
 custname | text    |           | not null | 
Indexes:
    "customer_pkey" PRIMARY KEY, btree (custid)

Current Behavior

custid is of type integer on the database

Expected Behavior

custid should be of type text instead.

See Reporting Issues for more tips on writing good issues

[dhmlau]

FYI - my sample repo is here: https://github.com/dhmlau/loopback4-example-todo-customized

The workaround for me is to alter the table after being created using npm run migrate.

testdb=# ALTER TABLE customer ALTER COLUMN custid TYPE text;
ALTER TABLE
testdb=# \d customer
                              Table "public.customer"
  Column  | Type | Collation | Nullable |                 Default                  
----------+------+-----------+----------+------------------------------------------
 custid   | text |           | not null | nextval('customer_custid_seq'::regclass)
 custname | text |           | not null | 
Indexes:
    "customer_pkey" PRIMARY KEY, btree (custid)

[bajtos]

I think the PostgreSQL connector is enforcing the type of the primary key to be a number. You can see that the custid column is configured to use a default value computed by nextval('customer_custid_seq'::regclass).

I think the same problem may apply to other SQL connectors too.

While this behavior is intended, I can see how it can be confusing for people building LB4 applications.