Unable to addSelect with computed result

when using a computed selection the property doesn’t get hydrated

@Entity()
export class Post {

    @PrimaryGeneratedColumn()
    id: number;

    @Column()
    title: string;

    @Column({ type: String, nullable: true })
    text: string|null;
}

const query = connection.manager.createQueryBuilder(Post, "post");
const loadedPost = await query
    .select("post.id")
    .addSelect("SUBSTRING(post.text, 1, 20)", "post_text")
    .getOne();

if (!loadedPost.text) {
   throw new Error('text not hydrated');
} else if (loadedPost.length > 20) {
  throw new Error('text length to large');
} else {
  console.log('everything is all good')
}

Expected Behavior

This would output everything is all good.

Actual Behavior

Error is thrown: text not hydrated

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

I’ve already fixed this issue in this PR: #4703 but it seems to getting ignored due to the fact that it doesn’t support all use cases of the parties involved that are mainly interested in addSelectAndMap. But because a feature PR for that is currently in the works #6855, i think that we can just merge #4703 as it doesn’t introduce any new features but fixes a Very long standing bug.

[nebkat]

@Asarew I share your frustration at the lack of this feature for so long but this really isn’t constructive. The developers are clearly aware of this and you are simply wasting their time by creating new issues. I am working on a solution that will hopefully satisfy all parties because personally I don’t think any of the provided solutions are actually going to be good long term.

[nebkat]

Please take a look at my proposed pull request for selectAndMap then, I think it achieves precisely what you mentioned since it uses the same type mapping as @Column, which also includes the option for a valueTransformer.

A core part of any ORM is that it does the mapping of raw database output to the object for you (its literally in the name I guess). As far as the designer is concerned, the only thing that really matters is the entity and its properties - how the ORM chooses to map from the object to the database and vice-versa is not nearly as important.

Of course, sometimes we care about the names assigned to columns because they might be read directly from a non-ORM client, which is why we are given the freedom to define the column names ourselves, both manually and through naming schemes. Beyond that however, the ability of the ORM to map my_custom_column_name to user.id should be considered an internal process.

TypeORM happens to do this by generating column aliases in the form ${tableAlias}_${databaseName}, which looks fairly “standard”, but it is still an internal process. It could be changed to a hash of this value, use a double underscore, etc, for a variety of reasons. One example for such a change would be to avoid a conflict between ${'user'}_${'post_id'} and ${'user_post'}_${'id'}. This is why it is important to keep this considered an internal process. Right now this change could be made internally and it would have 0 effect on existing setups, meaning it can be made as part of a minor release rather than a major release.

If your proposed change is adopted we then mix the internal mapping process with user input, when in reality you should not care about how the ORM goes about achieving this internally. addSelect does have an alias parameter but it is currently only used within the select statements themselves rather than being mapped to a property. In that case, since both the declaration of the alias and its subsequent use in where, order by, etc, are done by the designer, there is no risk of an internal change affecting it.