Bug with @VirtualColumn not being returned correctly

[macleysousa]

Issue description

@VirtualColumn not being returned correctly

Expected Behavior

@Entity({ name: 'integrations' })
export class IntegrationEntity {
  @Exclude()
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @ApiProperty()
  @PrimaryColumn({ name: 'client_id', type: 'uuid' })
  client_id: string;

  @ApiProperty()
  @VirtualColumn({ query: (alias) => `select "DMS" from config_client where "client_id"=${alias}.client_id` })
  dms: string;
}

It was expected that @VirtualColumn would return the correct values according to the logic defined in the decorator.

{
  "client_id": "1b97a2d2-91b8-4dab-9593-906da6d95d36",
  "dms": "NBS"
}

Actual Behavior

@Entity({ name: 'integrations' })
export class IntegrationEntity {
  @Exclude()
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @ApiProperty()
  @PrimaryColumn({ name: 'client_id', type: 'uuid' })
  client_id: string;

  @ApiProperty()
  @VirtualColumn({ query: (alias) => `select "DMS" from config_client where "client_id"=${alias}.client_id` })
  dms: string;
}

DNS column is not being returned

{
  "client_id": "1b97a2d2-91b8-4dab-9593-906da6d95d36"
}

Steps to reproduce

1. Add the @VirtualColumn decorator to an entity or class.
2. Define the expected logic for the virtual value.
3. Observe the obtained result.

My Environment

Dependency	Version
Operating System	windows 10
Node.js version	18.18.0
Typescript version	5.3.3
TypeORM version	0.3.19

Additional Context

No response

Relevant Database Driver(s)

• aurora-mysql
• aurora-postgres
• better-sqlite3
• cockroachdb
• cordova
• expo
• mongodb
• mysql
• nativescript
• oracle
• postgres
• react-native
• sap
• spanner
• sqlite
• sqlite-abstract
• sqljs
• sqlserver

Are you willing to resolve this issue by submitting a Pull Request?

Yes, I have the time, and I know how to start.

[nodegin]

Same here, with latest 0.3.19.
Locking the version to 0.3.17 fixed it.
Not sure if breaking changes introduced in 0.3.18 or 0.3.19.

[nodegin]

https://github.com/typeorm/typeorm/pull/10432/files

[jorenvandeweyer]

How do you select the virtual column, can you give an example of the implementation?

[kevinwilson541]

As an example, usage of the repository findOne or findOneOrFail functions, without the select option, will return virtual columns by default in version 0.3.17. Version 0.3.19 omits virtual columns with the same usage pattern.

[NarHakobyan]

Yeah, we are experiencing the same issue, virtual column stopped working. this is urgent‼️

[jorenvandeweyer]

Can you create a PR to fix the issue introduced in #10432 but also keep #10431 fixed? If not, I think we should create a PR reverting the changes from #10432

[macleysousa]

@jorenvandeweyer
I think we should create a PR reverting the changes from #10432, because analyzing the code from PR #10432 it just made all virtual columns return null, in his case I think he should use a transformation to convert empty to null

[fatlirmorina]

Same here ->

Upgraded from 0.3.17 to 0.3.19 (latest) and everything related to VirtualColumn breaks.

[EliezerMafra]

Same here ->
the @VirtualColumn decorator does not work on 0.3.19 version

[PatrickWe]

I have the Same issue.

Upgraded from 0.3.17 to 0.3.19 and everything related to VirtualColumn breaks.

[AmrAnwar]

not working with us too after update from 0.3.17

[martin-scholz-emnify]

still broken in 0.3.20

[gwen1230]

Any news on open MR ?

[nodegin]

@gwen1230 I think they are not going to fix this because not much people are using virtual column, so for stability either downgrade or switch to Prisma instead.

[strongpauly]

I've seen this too after upgrading. A possible workaround is to pass a select which includes the virtual column, but this isn't great as you then have to pass all the fields that you want to be returned.

[Dawar]

I've seen this too after upgrading. A possible workaround is to pass a select which includes the virtual column, but this isn't great as you then have to pass all the fields that you want to be returned.

Tried this but didn't seem to work, TypeORM is trying to load the column from the actual table. Did you have any success with it?

If the general direction is to manually select virtualcolumns that would also be fine (there should probably be an eager option on the decorator in that case). The previous virtualcolumn functionality was ideal imo. Curious why these breaking changes were implemented from a benefit stand-point.

Will try and compare prev and curr implementation for possible ideas

[d3tr1tus]

Any updates? I would appreciate some fix here it will be really helpful 🙏🏼

[ernes128]

any updates on this?

[tristin-terry]

A fix for this would be helpful, we were just affected by this in production and are going to have to downgrade or patch it internally until it is fixed!

hopefully either #10777 or #10698 can be reviewed soon!

[fatlirmorina]

Any news on this, please?

Many production environments are affected by this, please.

[nodegin]

@fatlirmorina The solution is to install 0.3.17

[jsnazaroff]

Any news on this

[PatrickWe]

Any news on this

[ReneeDress]

Any news on this

[macleysousa]

Any news on this

Unfortunately not, still awaiting PR approval.

[krishnabrq]

Have you got any update on this yet?

[macleysousa]

Have you got any update on this yet?

Unfortunately still no response. I'm already thinking about creating a fork of the project.

[Pyakz]

+1

[Helveg]

I'd also like to offer my own fork as a solution. I took e7649d2 and applied the fix of #10698, and it is published as @helveg/typeorm. I won't maintain the fork any further, but people looking for typeorm 0.3.20 with working VirtualColumns can install it with the following npm-alias:

npm install typeorm@npm:@helveg/[email protected]

which will fix this issue.

[luscala]

+1

[DarthSnufkin]

+1

[EliezerMafra]

+1

[alumni]

Does #10927 fix this issue?

[scr4bble]

Seems like there are several PRs which aim to fix this, right? I am not too deep in the issue but I see a lot of attention here and effort from several people to fix this.

PRs:
#10698
#10777
#10927

@pleerock could you please take a look at them (check whether they look good) and comment on what is needed to be done before they can be merged? (or basically any of them - whichever looks best and fixes the issue)

[alumni]

#10698 and #10777 revert the PR that introduced the issue. #10698 also adds some some tests.
#10927 reverts the PR that introduced the issue and fixes the original issue.

[Helveg]

People: TypeORM is abandoned. There are no active maintainers anymore. This issue is indeed fixed (a couple of times even) but there is noone to merge the fixes. The last commit is 8 months ago, there are 2.4k issues, and 160 open PRs.