Skip to content
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

Allow Class/Model Name to Have A Different Name From the Database Table #2134

Open
shadyanwar opened this issue Dec 8, 2018 · 10 comments
Open
Labels
CLI developer-experience Issues affecting ease of use and overall experience of LB users feature good first issue

Comments

@shadyanwar
Copy link

Description / Steps to reproduce / Feature proposal

Create/map a class/model with a name different from the name in its MySQL table

Current Behavior

If the class name is different, there is no way to map it to the correct table having a different name.

Expected Behavior

Just like individual properties inside the class, a class/model should be allowed to be exposed with a custom name different from that in the database table.

@dhmlau
Copy link
Member

dhmlau commented Dec 8, 2018

@shadyanwar , you can specify the model name that is different from the table name.
Cross posting my comment in https://github.com/strongloop/loopback/issues/4086#issuecomment-445015678:

@model({
  settings: {
    postgresql: {
      table: 'customer',
    },
  },
})
export class Customer2 extends Entity {

@dhmlau dhmlau self-assigned this Dec 8, 2018
@shadyanwar
Copy link
Author

shadyanwar commented Dec 8, 2018

Worked like a charm! Thank you!
It would seriously help if the "lb4 model" command added this automatically as a start. The developer can then manually modify it if desired.

@bajtos
Copy link
Member

bajtos commented Dec 11, 2018

It would seriously help if the "lb4 model" command added this automatically as a start. The developer can then manually modify it if desired.

This is a great suggestion. Would you @shadyanwar like to contribute this improvement yourself?

Let's reopen this issue to keep track of this enhancement.

@bajtos bajtos reopened this Dec 11, 2018
@bajtos bajtos added developer-experience Issues affecting ease of use and overall experience of LB users feature CLI good first issue labels Dec 11, 2018
@shadyanwar
Copy link
Author

@bajtos Sure. Could you please point to me where to look? I thought it would be https://github.com/strongloop/loopback-cli/blob/master/bin/loopback-cli.js

@dhmlau
Copy link
Member

dhmlau commented Dec 13, 2018

@shadyanwar, the CLI code for LB4 can be found in the cli package: https://github.com/strongloop/loopback-next/tree/master/packages/cli.

@bajtos @shadyanwar, I'm not sure if adding the database/table information as part of the lb4 model would be a good idea. Supposedly, at the point of creating a model, someone may not know or care about how it connects to a database?

@bajtos
Copy link
Member

bajtos commented Dec 13, 2018

I'm not sure if adding the database/table information as part of the lb4 model would be a good idea. Supposedly, at the point of creating a model, someone may not know or care about how it connects to a database?

Fair point.

In LB4, it's possible to attach a single model to multiple datasources (databases). For long term, we may want to find a way how to specify the table name at repository level.

At the moment, the only solution for customizing table name is to use database-specific model configuration as shown in #2134 (comment).

As I am thinking about this more, I see a different problem: the table name is specific to a connector (e.g. postgresql: {table: 'Customer'}}). When creating a new model via lb4 model, we don't know what connector will be backing the new model, that decision is made later when creating a repository for the new model and choosing which datasource to use.

So at the end, I am not sure what to change. I guess the best option is to enhance our model template with a comment showing users how to add custom configuration?

The template in loopback-next/packages/cli/generators/model/templates/model.ts.ejs generates the following TypeScript code now:

@model()
export class Customer extends Entity {

Proposed new version:

@model({
  settings: {
    // Configure model settings here, e.g. set a custom table name
    // https://loopback.io/doc/en/lb3/Model-definition-JSON-file.html#data-source-specific-options
  }
})
export class Customer extends Entity {

@strongloop/loopback-maintainers thoughts?

@yueshaohui
Copy link

@shadyanwar , you can specify the model name that is different from the table name.
Cross posting my comment in https://github.com/strongloop/loopback/issues/4086#issuecomment-445015678:

@model({
  settings: {
    postgresql: {
      table: 'customer',
    },
  },
})
export class Customer2 extends Entity {

It seems like DB2 doesn't work in this way

@yueshaohui
Copy link

yueshaohui commented Aug 13, 2020

@model({
  settings: {
    db2: {
      table: 'usage',
      schema: 'att'
    },
  },
})

even I add code above I still get the same issue

[CLI Driver][DB2/LINUXX8664] SQL0204N  "SHAO.usage" is an undefined name.  SQLSTATE=42704

I don't know why it always uses my user name SHAO as to be the schema but not att.

@dhmlau
Copy link
Member

dhmlau commented Aug 13, 2020

@yueshaohui, I think you need to specify the schema in the DataSource.

@yueshaohui
Copy link

yueshaohui commented Aug 14, 2020

@yueshaohui, I think you need to specify the schema in the DataSource.

Yes, Actually I have a schema configured in my DataSource, and everything running well as connecting DB2 in a general way.
But I'm trying to access to DB2 in DSN way, it can't be able to map schema correctly.

Thanks for your help

following is the configuration in my DataSource

config: {
    "dsn": DATABASE=${DATABASE};HOSTNAME=${HOST};PORT=${PORT};PROTOCOL=TCPIP;UID=${USERID};PWD=${PASSWORD};Security=SSL;
    "name": "test",
    "connector": CONNECTOR,
    "host": HOST,
    "port": PORT,
    "user": USERID,
    "password": PASSWORD,
    "database": DATABASE,
    "schema": "ATT"
  }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLI developer-experience Issues affecting ease of use and overall experience of LB users feature good first issue
Projects
None yet
Development

No branches or pull requests

4 participants