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

When using base class' custom repository, the discriminator is ignored #2927

Closed
ryuuji3 opened this issue Oct 13, 2018 · 7 comments · Fixed by #8819
Closed

When using base class' custom repository, the discriminator is ignored #2927

ryuuji3 opened this issue Oct 13, 2018 · 7 comments · Fixed by #8819

Comments

@ryuuji3
Copy link

ryuuji3 commented Oct 13, 2018

Issue type:

[x ] question
[x ] bug report
[ ] feature request
[ ] documentation issue

Database system/driver:

[ ] cordova
[ ] mongodb
[ ] mssql
[ ] mysql / mariadb
[ ] oracle
[x ] postgres
[ ] sqlite
[ ] sqljs
[ ] react-native
[ ] expo

TypeORM version:

[x ] latest
[ ] @next
[ ] 0.x.x (or put your version here)

Steps to reproduce or a small repository showing the problem:

I have a Single Table Inheritance structure; User and its child classes. At some point I am saving an instance of User's child class created with the appropriate constructor;

  static getUserInstanceFromPayload(payload: IUserPayload) {
    switch(payload.role) {
      case UserRole.ADMIN: return new Admin(); // class Admin extends User
      default: throw new Error(`Invalid role ${role}`);
    }
  }
  /* elsewhere... */
  const payload = req.payload as IUserPayload;
  const repository = em.getCustomRepository(User);
  const user = getUserInstanceFromPayload(payload);

  user.populateFromPayload(payload);

  return repository.save(user);

So I receive a payload object and then match the role and choose the appropriate constructor so that it should be the right kind of entity, and then populate it and save.

However, when I run this code, I receive this error:

Query failed: INSERT INTO "user"("id", "username", "password", "firstName", "lastName", "createdDate", "lastUpdatedDate", "role") VALUES (DEFAULT, $1, $2, $3, $4, DEFAULT, DEFAULT, $5) RETURNING "id", "createdDate", "lastUpdatedDate", "role" -- PARAMETERS: ["joe.schmoe@example.com","$2b$07$J4XESA9hrVFJPpG.Xjfo0.zv9HOB4cd3T2xLxbEI37N20Dvx11TsG","Joe","Schmoe","User"]
Error: error: invalid input value for enum user_role_enum: "User"

So I see that when it saves, it is somehow obtaining "User" as the discriminator value from the repository.

My solution has been to use the EntityManager to save the entity and it works as expected. So it's not like it's impossible to do what I want.

return em.save(user); // works as expected

Additional info:

enum UserRole {
  ADMIN = "ADMIN",
  // etc...
}

My User entity:

@Entity()
@TableInheritance({
  column: {
    name: "role",
    type: "enum",
    enum: UserRole,
    default: UserRole.BASIC_USER
  }
})
export abstract class User {
  @Expose()
  protected role: UserRole;
}

And the admin:

@ChildEntity(UserRole.ADMIN)
export class Admin extends User {

  constructor() {
    super();

    this.role = UserRole.ADMIN; // this is only here so that unit tests work
  }
}
@ryuuji3
Copy link
Author

ryuuji3 commented Dec 28, 2020

Closing because this hasn't had any response.

@ryuuji3 ryuuji3 closed this as completed Dec 28, 2020
@pekunicki
Copy link

pekunicki commented Apr 9, 2021

This issue still occurs, so would be worth resolving it.
The solution with entity manager does not work great when you have a collection of multiple items of different types.

felix-gohla added a commit to giz-berlin/typeorm that referenced this issue Mar 28, 2022
When using a STI scheme and an EntityManager or Repository
with base class target, the wrong discriminator was written to the
database despite giving an concrete entity.
This was because of the entity's target being ignored in favor of the
target of the Repository or the EntityManager.

fixes typeorm#2927
felix-gohla added a commit to giz-berlin/typeorm that referenced this issue Mar 28, 2022
When using a STI scheme and an EntityManager or Repository
with base class target, the wrong discriminator was written to the
database despite giving an concrete entity.
This was because of the entity's target being ignored in favor of the
target of the Repository or the EntityManager.

fixes typeorm#2927
felix-gohla added a commit to giz-berlin/typeorm that referenced this issue Mar 28, 2022
When using a STI scheme and an EntityManager or Repository
with base class target, the wrong discriminator was written to the
database despite giving an concrete entity.
This was because of the entity's target being ignored in favor of the
target of the Repository or the EntityManager.

fixes typeorm#2927
felix-gohla added a commit to giz-berlin/typeorm that referenced this issue Mar 28, 2022
When using a STI scheme and an EntityManager or Repository
with base class target, the wrong discriminator was written to the
database despite giving an concrete entity.
This was because of the entity's target being ignored in favor of the
target of the Repository or the EntityManager.

fixes typeorm#2927
felix-gohla added a commit to giz-berlin/typeorm that referenced this issue Mar 30, 2022
When using a STI scheme and an EntityManager or Repository
with base class target, the wrong discriminator was written to the
database despite giving an concrete entity.
This was because of the entity's target being ignored in favor of the
target of the Repository or the EntityManager.

fixes typeorm#2927
pleerock pushed a commit that referenced this issue Apr 2, 2022
When using a STI scheme and an EntityManager or Repository
with base class target, the wrong discriminator was written to the
database despite giving an concrete entity.
This was because of the entity's target being ignored in favor of the
target of the Repository or the EntityManager.

fixes #2927
@bombillazo
Copy link

Still an existing issue.

@Distortedlogic
Copy link

Distortedlogic commented Sep 6, 2022

Still an existing issue in v0.2.45 .. is this fixed in a later v3 version?

@bombillazo
Copy link

@Distortedlogic Nope, still an issue in v0.3.9

@Distortedlogic
Copy link

@bombillazo seems it was supposed to be fixed in like v0.3.5

06-09-2022-11-03-44

#8819

@bombillazo
Copy link

My bad! You are correct, I had fixed it, I was missing the discriminator type as the parameter of the decorator! Sorry for the confusion. 😖

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

Successfully merging a pull request may close this issue.

6 participants