feat: implement new virtual decorator

[CollinCashio]

Description of change

Add a new feature that Fixes #9323

Pull-Request Checklist

• Code is up-to-date with the master branch
• npm run format to apply prettier formatting
• npm run test passes with this change
• This pull request links relevant issues as Fixes #0000
• There are new or updated unit tests validating the change
• Documentation has been updated to reflect this change
• The new commits follow conventions explained in CONTRIBUTING.md

[Ginden]

"Calculated column" is term associated with PowerBI. "Computed column" refers to specific feature in multiple databases. Maybe call it "virtual column"?

Generally, good job!

[CollinCashio]

"Calculated column" is term associated with PowerBI. "Computed column" refers to specific feature in multiple databases. Maybe call it "virtual column"?

Generally, good job!

Thank you. I really think this feature will add value to the community.

If you look at the history of the issue that I posted I originally called the calculated column decorator a "VirtualColumn" decorator because I believe that this is a better name myself, but the entity column Metadata already had a property being used for IsVirtual, so I figured I should go with a new name. I can for sure update this to VirtualColumn especially since like you said it is a better name, and I can add a new property called isVirtualDecorator to the entity column Metadata.

This feature has been renamed @Ginden back to to VirtualColumn

[CollinCashio]

How are we looking on this @Ginden ? It has been a week since our last discussion, and I want to ensure that this PR doesn't get lost in the backlog. Can this get merged in or is there something outstanding I need to do on my end?

[Ginden]

I'm merely helping with issues and reviews, to get them streamlined faster. At the end of day, decision, especially design decisions, belongs to @pleerock and other higher level maintainers.

[bjoveski]

thank you for doing this, this would be an extremely useful feature for us!

[H6LS1S]

@pleerock Сan this be released as a standalone release if it doesn't make it into the main release soon? This is a very useful feature for our project ( i think for others too ) after migrating from mikro-orm to typeorm

[pleerock]

Thank you a lot for this contribution! Quite a solid implementation!

[joeruello]

@pleerock Was looking for something like this today and found it hasn't been released yet :(. Any ETA on when the next release will be cut with this PR included?

[pleerock]

you can actually start using it in the latest dev version (check npm versions)

[kerhong]

This PR introduced a very breaking change about default behavior for number columns without specific type added.

class Foo {
    @Column()
    bar!: number;
}

This is now always pushed through parseInt (https://github.com/typeorm/typeorm/pull/9339/files#diff-3346a7798b4db06d6debd87138bb8322626b91c1c325b730d51ee3afc1b4c2bbR798-R800) and is therefore an integer, previously it worked fine with a floating point.

Was this change intended? Seems completely unrelated to the original function of this PR.

cc @pleerock

[pleerock]

I'm not sure why these changes were needed, let's ask @CollinCashio

But in what cases previously it worked? @Column() bar: number always maps to int, if you want to use floating numbers, you must specify a type, e.g. @Column("double") bar: number

[kerhong]

@pleerock Than's for your quick response. Here is the use where I found this issue.

1. typeorm@0.3.10
2. Migration with

   new TableColumn({
     name: 'foo',
     type: 'float',
   }),

3. Entity with

   @Column()
   foo!: number;

This would not round/floor the value, entity would contain the full float on fetch.

I am not sure to what extent should @Column() contain TableColumnOptions, it can be omitted, and all fields are optional.
Is there some documentation that explains how strictly the column details must be preserved between migrations and entities? Is there a way to validate entities against schema and/or migrations?

[pleerock]

I would avoid complicating the report with migrations. I'm not sure where did you get the migration you wrote - if it's manually written, then it's not valid since it differs from the entity definition.

The best if you always specify column type in @Column decorator to be explicit. By default, again number type without @Column type specification maps to int. So in your case for your migration the valid column definition must be @Column("float") foo!: number;.

[kerhong]

@pleerock Thanks for the clarification, I wasn't aware that number is treated as int.

[Abobos]

I have a question. Can't the query be optional?.. I don't need to perform a subquery when I use a virtualColumn.

For context: https://pietrzakadrian.com/blog/virtual-column-solutions-for-typeorm#5-decorator-method

[Abobos]

@CollinCashio

[sschneider-ihre-pvs]

what if the virtualcolumn is not in the database at all but some other computed value?

[sschneider-ihre-pvs]

background would be graphql since if you want a unique id field and have a composite key for a table you want to cramp that into a single key maybe

[CollinCashio]

Hey @Abobos and @sschneider-ihre-pvs ,

This functionality was designed specifically for subqueries. This solves the need of allowing your database engine to return queried result sets and put the data into your defined model (also allows you to use the DB engine to filter data from the model).

If you are just looking for a readonly property that has no need to pull database information and possibly pull from a third party API or some other data source, you could just use a regular property without any column decorator. IE your model could look like:

@Entity({ name: "timesheets" })
export default class TimeSheet extends BaseEntity {
    @PrimaryGeneratedColumn()
    id: number;

    hours: number;

    @AfterLoad()
    afterLoad() {
         // perform calculations here to set property of hours
    }
}

[Abobos]

@CollinCashio VIrtual Column suffices for my use-case.. but I was thinking you can just add the column name as some alias in a query without having to do a subquery.

Thanks

[effective-giggle]

This PR created bug #10026