Loopback-next: LB3 model import: preserve connector-specific metadata in property definitions

[bajtos]

Consider the following LB3 model definition:

{
  "name": "Product",
  "base": "PersistedModel",
  "properties": {
    "name": {
      "type": "string",
      "required": true,
      "mysql": {
        "column": "NAME",
        "length": 80,
      }
    }
  }
}

Expected property definition in LB4 model file:

@property{
  type: 'string',
    mysql: {
      column: 'NAME',
      length: 80,
    },
})
name: string;

• UPDATED Acceptance criteria (02/24/2020) based on https://github.com/strongloop/loopback-next/issues/3810#issuecomment-589372507

Acceptance criteria

• [x] add migration unit tests for preserving db metadata in model properties
• [x] check a migrated lb-next app manually that was migrated from an lb3 app with the above criteria
• [x] open additional issues for any open challenges migrating apps with above criteria
• [x] Update Importing-LB3-models.md, remove the relevant point from the list of known limitations
• [x] remove blocks on dependent issues (https://github.com/strongloop/loopback-next/issues/3814)

[deepakrkris]

@bajtos I find that lb4 import-lb3-models command already supports including connector metadata in property definitions (I checked out of curiosity because the existing code does not restrict flowing of db metadata from lb3)

[deepakrkris]

I was able to create the following typescript class from the LoopBack 3x db example , Todo model json
public.todo.json.txt ,

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

@model({
  settings: {
    replaceOnPUT: false,
    postgresql: {schema: 'public', table: 'todo'},
    idInjection: true
  }
})
export class Todo extends Entity {
  @property({
    type: 'number',
    required: true,
    precision: 64,
    scale: 0,
    id: true,
    postgresql: {columnName: 'id', dataType: 'bigint', dataLength: null, dataPrecision: 64, dataScale: 0, nullable: 'NO'},
  })
  id: number;

  @property({
    type: 'string',
    length: 25,
    postgresql: {columnName: 'title', dataType: 'character varying', dataLength: 25, dataPrecision: null, dataScale: null, nullable: 'YES'},
  })
  title?: string;

  @property({
    type: 'string',
    length: 25,
    postgresql: {columnName: 'desc', dataType: 'character varying', dataLength: 25, dataPrecision: null, dataScale: null, nullable: 'YES'},
  })
  desc?: string;

  @property({
    type: 'boolean',
    postgresql: {columnName: 'iscomplete', dataType: 'boolean', dataLength: null, dataPrecision: null, dataScale: null, nullable: 'YES'},
  })
  iscomplete?: boolean;

  @property({
    type: 'number',
    precision: 64,
    scale: 0,
    postgresql: {columnName: 'todolistid', dataType: 'bigint', dataLength: null, dataPrecision: 64, dataScale: 0, nullable: 'YES'},
  })
  todolistid?: number;

  // Define well-known properties here

  // Indexer property to allow additional data
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  [prop: string]: any;

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

export interface TodoRelations {
  // describe navigational properties here
}

export type TodoWithRelations = Todo & TodoRelations;

[deepakrkris]

I tried changing the property name of desc to desc2 just to check if the column metadata is used indeed, and it all works perfectly.

[bajtos]

I find that lb4 import-lb3-models command already supports including connector metadata in property definitions
I tried changing the property name of desc to desc2 just to check if the column metadata is used indeed, and it all works perfectly.

That's awesome, it means we have less work to do 🚀

Your updated Acceptance criteria looks good to me.

• [x] add migration unit tests for preserving db metadata in model properties
• [x] check a migrated lb-next app manually that was migrated from an lb3 app with the above criteria
• [ ] open additional issues for any open challenges migrating apps with above criteria
• [x] Update Importing-LB3-models.md, remove the relevant point from the list of known limitations
• [x] remove blocks on dependent issues (https://github.com/strongloop/loopback-next/issues/3814)